サーチ…
サブモジュールの追加
別のGitリポジトリを、Gitによって追跡されるプロジェクト内のフォルダとして含めることができます：
$ git submodule add https://github.com/jquery/jquery.git
新しい.gitmodulesファイルを追加してコミットする必要があります。 git submodule updateが実行されたときに、どのサブモジュールをクローンするべきかをGitに伝えます。
サブモジュールを持つGitリポジトリのクローン作成
サブモジュールを使用するリポジトリをクローンするときは、それらを初期化して更新する必要があります。
$ git clone --recursive https://github.com/username/repo.git
これにより、参照されたサブモジュールがクローンされ、適切なフォルダ（サブモジュール内のサブモジュールを含む）に配置されます。これは、クローンが終了した直後にgit submodule update --init --recursiveを実行するのと同じです。
サブモジュールの更新
サブモジュールは別のリポジトリ内の特定のコミットを参照します。すべてのサブモジュールで参照されている正確な状態をチェックするには、
git submodule update --recursive
場合によっては、参照されている状態を使用する代わりに、ローカルのチェックアウトをリモートのサブモジュールの最新の状態に更新する必要があります。 1つのコマンドですべてのサブモジュールをリモートの最新の状態にチェックアウトするには、
git submodule foreach git pull <remote> <branch>
デフォルトのgit pull引数を使用する
git submodule foreach git pull
これはローカル作業コピーを更新するだけであることに注意してください。 git statusを実行すると、このコマンドのためにサブモジュールディレクトリが変更された場合、そのサブモジュールディレクトリがdirtyと表示されます。代わりに新しい状態を参照するようにリポジトリを更新するには、変更をコミットする必要があります。
git add <submodule_directory>
git commit
git pullを使用している場合、 git pull --rebaseを使用して変更を上に戻すことができます。ほとんどの場合、競合の可能性が低くなります。また、すべてのブランチをローカルに引き出します。
git submodule foreach git pull --rebase
特定のサブモジュールの最新の状態をチェックアウトするには、以下を使用できます。
git submodule update --remote <submodule_directory>
サブモジュールをブランチに従うように設定する
サブモジュールは常に、特定のコミットSHA1（ "gitlink"、親リポジトリのインデックス内の特別なエントリ）でチェックアウトされます。
しかし、サブモジュールリモートリポジトリのブランチの最新のコミットにそのサブモジュールを更新するよう要求することができます。
各サブモジュールに行くのではなく、 git checkout abranch --track origin/abranch, git pullを実行すると、（親リポジトリから）単純に行うことができます。
git submodule update --remote --recursive
サブモジュールのSHA1が変更されるので、あなたはそれに続く必要があります：
git add .
git commit -m "update submodules"
それはサブモジュールが次のものだったと仮定します：
フォローするブランチを追加するか、
git submodule -b abranch -- /url/of/submodule/repo既存のサブモジュールのためにブランチに従うように設定することができます。
cd /path/to/parent/repo git config -f .gitmodules submodule.asubmodule.branch abranch
サブモジュールの削除
サブモジュール（例： the_submodule ）を呼び出すには：
$ git submodule deinit the_submodule
$ git rm the_submodule
git submodule deinit the_submoduleは.git / configからthe_submoduleのエントリを削除します。これはthe_submoduleをgit submodule update、git submodule sync、git submodule foreach呼び出しから除外し、ローカルコンテンツ（ソース）を削除します。また、これは親リポジトリに変更として表示されません。git submodule initとgit submodule updateは、親リポジトリにコミット可能な変更を加えずに、サブモジュールを復元します。git rm the_submoduleは、サブモジュールを作業ツリーから削除します。ファイルは.gitmodulesファイル（ソース）内のサブモジュールのエントリと同様になくなります。ただし、git rm the_submodule（以前のgit submodule deinit the_submoduleが実行されていない場合は、.git / configファイル内のサブモジュールのエントリはそのまま残ります）。
-
.gitmodulesファイルから該当するセクションを削除します。 - ステージを
.gitmodules変更git add .gitmodules -
.git/configから該当するセクションを削除します。 -
git rm --cached path_to_submodule実行します（末尾にスラッシュはありません）。 -
rm -rf .git/modules/path_to_submodule実行します。 - Commit
git commit -m "Removed submodule <name>" - 未追跡のサブモジュールファイルを削除する
-
rm -rf path_to_submodule
サブモジュールの移動
実行：
$ git mv old/path/to/module new/path/to/module 1.8 .gitmodulesを編集し、サブモジュールのパスを適切に変更し、 git add .gitmodules使ってインデックスに入れてgit add .gitmodules 。
必要に応じて、サブモジュールの新しい場所の親ディレクトリを作成します（ mkdir -p new/path/to ）。
すべてのコンテンツを古いディレクトリから新しいディレクトリに移動します（ mv -vi old/path/to/module new/path/to/submodule ）。
Gitがこのディレクトリを追跡していることを確認してください（ git add new/path /to ）。
git rm --cached old/path/to/module古いディレクトリを削除しgit rm --cached old/path/to/module 。
すべての内容を.git/modules/ new/path/to/module .git/modules/ old/path/to/module 、ディレクトリ.git/modules/ old/path/to/module移動し.git/modules/ new/path/to/module 。
.git/modules/ new/path/to /configファイルを編集し、worktree項目が新しい場所を指していることを確認してください。この例ではworktree = ../../../../../ old/path/to/module 。典型的には、その場所の直接経路に2つ以上のディレクトリが存在するはず.. 。 。 new/path/to/module /.gitファイルを編集し、そのパスがメインプロジェクトの.gitフォルダ内の正しい場所を指していることを確認します。この例ではgitdir: ../../../.git/modules/ new/path/to/module 。
git status出力は後で次のようになります：
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: .gitmodules
# renamed: old/path/to/submodule -> new/path/to/submodule
#
最後に、変更をコミットします。
Axel BeckertによるStack Overflowのこの例
Modified text is an extract of the original Stack Overflow Documentation
ライセンスを受けた CC BY-SA 3.0
所属していない Stack Overflow