最終的には、興味深いソフトウェアプロジェクトは別のプロジェクト、ライブラリ、またはフレームワークに依存するようになります。 Gitはこれに役立つサブモジュールを提供します。 Submodulesきたものではありま組み込みが一つ以上のリポジトリとサブフォルダの中に別のリポジトリ
多くのプロジェクトでは、サブモジュールは最良の答えではなく（これについては後述）、最高の状態でさえ、サブモジュールを扱うのは難しいかもしれませんが、まず簡単な例を見てみましょう。,
サブモジュールの追加
Slingshotというプロジェクトに取り組んでいるとしましょう。 あなたはのコードを持っていますy-shaped stickそしてarubber-band。
クリエイティブ—コモンズ（BY）ライセンスの下でyoung@artが共有するflickr写真
同時に、別のリポジトリには、Rockと呼ばれる別のプロジェクトがあります。rockライブラリですが、パチンコには最適だと思います。
追加できますrockのサブモジュールとしてslingshot。, slingshotリポジトリ：
この時点で、rockslingshot内のフォルダがありますが、そのフォルダ内を覗くと、Gitのバージョンによっては、何も表示されないかもしれません。,
新しいバージョンのGitではこれが自動的に行われますが、古いバージョンではGitにrock:
すべてが正常に見える場合は、この変更をコミットすることができ、rockslingshotrockリポジトリからのすべてのコンテンツを持つリポジトリ。,
GitHubでは、rockフォルダアイコンには、それがサブモジュールであることを示す小さなインジケータがあります。
rockフォルダをクリックすると、rockフォルダがrockリポジトリ。
それで終わりです！ rockリポジトリをslingshotリポジトリ内に埋め込みました。 からすべてのコンテンツを操作できますrockまるでslingshot内のフォルダーであるかのように（そうであるため）。,
コマンドラインでは、slingshot（または他のフォルダのいずれか、rubber-bandおよびy-shaped-stick）から発行されたGitコマンドは、”親リポジトリ”slingshotで動作しますが、iv id=”2e967c1e83″から発行されたコマンドはフォルダはrockリポジトリで動作します：
サブモジュールを使用してプロジェクトに参加する
さて、あなたはプロジェクトslingshotに参加する新しいコラボレーターであるとします。, まず、git cloneを実行して、slingshotリポジトリの内容をダウンロードします。 この時点で、rockフォルダー内を覗くと、何も表示されません。
ここでも、Gitはサブモジュールのコンテンツをダウンロードするよう明示的に要求することを期待しています。, ここでもgit submodule update --init --recursiveを使用できますが、slingshotを初めて複製する場合は、変更されたcloneコマンドを使用して、サブモジュールを含むすべてのものをダウンロードできます。
サブモジュールに切り替える
既存のサブフォルダを取り出して外部の依存関係に変換するのは少し難しいかもしれません。 例を見てみましょう。
新しいプロジェクトを開始しようとしています—魔法のロールバック缶-これにはrubber-bandも必要です。, rubber-bandslingshot用に構築した
をスタンドアロンリポジトリに分割し、サブモジュールを介して両方のプロジェクトに埋め込みます。
プロジェクトSlingshotのrubber-bandフォルダーからすべてを取得し、新しいリポジトリに抽出し、コミット履歴を維持することもできます。
まず、rubber-bandフォルダの内容をslingshotから抽出しましょう。, これを行うには、git filter-branchを使用して、rubber-bandに関連するコミットだけを残します。 git filter-branchコマンドは、リポジトリの履歴を書き換え、rubber-bandフォルダがすべて独自のリポジトリであったかのように見えます。 git filter-branchの詳細については、この記事を参照してください。
最初のステップは、slingshotのコピーを作成して作業することです—最終目標はrubber-band独自のリポジトリとして立つため、slingshot, cpと-rを使用して、slingshotフォルダー全体を新しいフォルダーrubber-bandに再帰的にコピーできます。,
rubber-bandはちょうど別のslingshotのように見えますが、rubber-bandリポジトリからgit filter-branch：
iv id=”fe71068ae5この時点で、rubber-bandというフォルダーがあり、これはproject slingshotに似ていますが、rubber-bandフォルダーからのファイルとコミット履歴,
これをslingshotからコピーしたので、新しいリポジトリには、slingshotのときに設定したリモート追跡ブランチがまだあります。 あなたはプッシュしたくないrubber-bandに戻ってslingshot。 これを新しいリポジトリにプッシュします。
GitHubでrubber-bandの新しいリポジトリを作成し、rubber-bandのリモートを更新します。, リモートoriginを呼び出していると仮定すると、次のことができます。
次に、git pushで新しい”汎用ラバーバンドモジュール”を公開することができます。,
rubber-bandを独自のリポジトリに分離したので、古いrubber-bandフォルダをslingshotリポジトリから削除する必要があります。
その後、slingshotを更新して使用するには、slingshotrubber-bandサブモジュールとして：
以前にrockを追加したときに見たように、リポジトリ内のリポジトリがあります。, 三つのリポジトリ、実際には：”親”リポジトリslingshot、プラス二つの”サブ”リポジトリ、rockとrubber-band。
さらに、slingshotの履歴に戻ると、もともとrubber-bandフォルダーだったときに行ったコミットが表示されます—フォルダーを削除しても履歴は消, これは時には少し混乱することがあります—rubber-band“child”リポジトリには、古いslingshotコミットのコピーおよび変更されたバージョンがあるため、時にはあなたがdéja vuを持っているように感じることがあります。
残念ながら、この時点でslingshotをプルする協力者は、空のrubber-bandフォルダーを持つことになります。,
rubber-bandサブモジュールをmagic roll-back canに追加することもできます。 幸いなことに、これを行う必要があるのは、”サブモジュールの追加”で、rockをslingshotに追加したときと同じ手順に従うことだけです。”
サブモジュールの使用に関するアドバイス(またはしない)
- サブモジュールとしてリポジトリを追加する前に、まず、より良い選択肢があるかどうか, Gitサブモジュールは単純なケースでは十分に機能しますが、最近ではGitサブモジュールが提供できるものよりも依存関係を管理するための優れたツールが Goのような現代の言語には、最初からフレンドリーでGit対応の依存関係管理システムが組み込まれています。 Rubyのrubygems、Nodeのような他のもの。js’npm、またはCocoaのCocoaPodsとCarthageは、プログラミングコミュニティによって追加されました。 でもフロントエン開発メンバーのリーディングプロジェクト亭管理図書館の枠組みのclient-side JavaScriptおよびCSS.
- こGitなダウンロードサブモジュールにより内容がデフォルトです。, 既存のプロジェクトにサブモジュールを追加する場合は、プロジェクトで作業するユーザーが
git submodule updateやgit clone --recursiveのようなコマンドを実行する必要があることを知っていることを確認してください。 ご使用をお勧めしますように当社の”スクリプトを原則全て”全ての共同研究者およびサービスへのアクセスと同リポジトリのコンテンツです。 - サブモジュールでは、一貫性と利便性のバランスを慎重に取る必要があります。, ここで使用されるセットアップは、少しの利便性を犠牲にして、一貫性を強く好みます。 一般的には、プロジェクトのサブモジュールを特定のSHAにロックして、すべての共同編集者が同じコンテンツを受け取るのが最善です。 しかし、この設定により、”親”リポジトリの開発者がサブモジュールリポジトリに変更を戻すことが困難になります。サブモジュールを更新する場合、同僚に
git submodule updateを実行するように思い出させる必要があるかもしれません。
または奇妙な動作が表示される,