Gitサブモジュールのワークフローの問題

Question

私たちは最近Gitリポジトリで多くの問題を抱えています。私たちは、gitサブモジュールのユーザーで、アプリケーション間で合計4つの共有リポジトリを使用しています。

たとえば、リポジトリ 'ウェブサイト'には合計3つのサブモジュールがあります。

[submodule "vendor/api"] 
    path = vendor/api 
    url = git@your.cool.domain.com:api 
[submodule "vendor/auth"] 
    path = vendor/auth 
    url = git@your.cool.domain.com:auth 
[submodule "vendor/tools"] 
    path = vendor/tools 
    url = git@your.cool.domain.com:tools 

私たちはメインリポジトリの「ウェブサイト」を正しくチェックアウトしました。今、私の同僚の1は、プッシュを行っているし、私git pull; git status：

# On branch master 
# Changed but not updated: 
# (use "git add <file>..." to update what will be committed) 
# (use "git checkout -- <file>..." to discard changes in working directory) 
# 
# modified: vendor/api (new commits) 
# modified: vendor/auth (new commits) 
# modified: vendor/tools (new commits) 
# 
no changes added to commit (use "git add" and/or "git commit -a") 

mcfly@future:~/projects/website$ git diff 

diff --git a/vendor/api b/vendor/api 
index 41795fc..b582d80 160000 
--- a/vendor/api 
+++ b/vendor/api 
@@ -1 +1 @@ 
-Subproject commit 41795fc4dde464d633f4c0f01eebb6ab1ad55582 
+Subproject commit b582d802419b0ee7bc3959e7623fec0b94680269 
diff --git a/vendor/auth b/vendor/auth 
index a00369b..4599a71 160000 
--- a/vendor/auth 
+++ b/vendor/auth 
@@ -1 +1 @@ 
-Subproject commit a00369bf29f14c761ce71f7b95aa1e9c107fb2ed 
+Subproject commit 4599a7179c9b7ca4afa610a15ffa4a8fc6ebf911 
diff --git a/vendor/tools b/vendor/tools 
index f966744..c678cf6 160000 
--- a/vendor/tools 
+++ b/vendor/tools 
@@ -1 +1 @@ 
-Subproject commit f966744359510656b492ae3091288664cdb1410b 
+Subproject commit c678cf6f599fc450e312f0459ffe74e593f5890f 

そのgit diffでの問題は何でしょうか。問題は、各サブモジュールの新しいコミットが、上書きされるよりも古いことです。リポジトリ上で正しく41795fc4dde464d633f4c0f01eebb6ab1ad55582、a00369bf29f14c761ce71f7b95aa1e9c107fb2edおよびf966744359510656b492ae3091288664cdb1410bを指しているので、これは私たちが望むものではありません。そして、この変更を次のコミットに追加すると、おそらくそれを制圧します。なぜ最新のものではなく最も古いリビジョンになっているのか分かりません。

私は自分でこの問題を解決しようとしたが、なし、成功しています

私たちは、おそらく各サブモジュールと、私たちの最新の「ウェブサイト」のポインタを更新するので、それは正しくないの最後のコマンドを行う

mcfly@future:~/projects/website$ git pull; git submodule foreach git pull 

これを望んでいない。リポジトリにある正しいリビジョンを保持したい。

私たちは通常、例えば、このサブモジュール内部の作業を行うことを説明してきたことの一つに：私たちはgit submodule updateを行うと

mcfly@future:~/projects/website$ cd vendor/api 
mcfly@future:~/projects/website/vendor/api$ git checkout master 
mcfly@future:~/projects/website/vendor/api$ echo "lorem ipsum" >> example.file 
mcfly@future:~/projects/website/vendor/api$ git add example.file; git push 

「マスター」ブランチは、すべてのサブモジュールに失われます。

最後に、push,を実行してサブモジュールを処理する正しい方法と、このような問題がすべて発生していないかどうかを確認します。

はgit-scm documentionを見て、あなたのチームにそれを周りに渡す事前

Answer 1

でいただきありがとうございます。あなたが見ている現象は、"Cloning a Project with Submodules"セクションに正確に記述されています。 git diffは、それらのための予期せず、反対の結果がハッシュをコミット示し

まず、あなたが観測され、初期状態では、あなたが親レポでサブモジュールの更新をマージされますが、ローカルでgit submodule updateを実行しなかった示しています。メインプロジェクトのサブモジュールの変更をプルダウンするたびにgit submodule updateを実行する必要があります。どうして？サブモジュールのポインタ、すなわち親リポジトリがvendor/authの状態であると考えるものは、サブモジュール・リポジトリvendor/authの実際にはHEADコミットではありません。 gitがどのようにサブモジュールの状態を追跡しているかを理解するまで、少し混乱します。繰り返しますが、git-scm documentationは読む価値があります。

第2に、git submodule updateは、サブモジュールのmasterブランチを設計上放棄します。これらのドキュメントの"Issues with submodules"セクションをご覧ください。多くの場合、gitの持つ真であるとしてmanページには、私たちが知っておくべきことを教えてくれる：

update 
    Update the registered submodules, i.e. clone missing submodules and checkout the commit specified in the index of the containing repository. This will 
    make the submodules HEAD be detached unless --rebase or --merge is specified or the key submodule.$name.update is set to rebase, merge or none. none 
    can be overridden by specifying --checkout. 

あなたは「切り離さHEAD」状態で使用すると、引数なしgit submodule updateを発行するたびに、あなたのサブモジュールを入れています。

こういった問題を起こさずにどのようにサブモジュールを扱うのですか？まず、あなたとあなたのチームに尋ねます：本当に必要なのですか？サブモジュールは、場合によっては強力で便利な機能ですが、サードパーティのライブラリでは、アクティブなプロジェクトがサブリポジトリに分割されているよりも多く設計されています。確かにこのように使用することはできますが、管理上のオーバーヘッドは、どんな利益を上回ってもすぐに上回る可能性があります。あなたのリポジトリが非常に大きいか、サブモジュールが完全にモジュール化されていない限り、質問する価値はあります"Would we be better off with a single repository?"答えが "いいえ"であっても、あなたのユースケースではより成功するかもしれないsubtree merging,をチェックしてください。

まだサブモジュールを使用したい場合は、上記のquestionsとanswersとサブモジュールワークフローに関するその他のサイトと同様に、上記にリンクされたthe docsをチェックしてください。彼らは、あなたがサマープロセスを達成するのを助けるべきです。