サーチ…
サブモジュールの追加
別の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