7

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

たとえば、リポジトリ「website」には合計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

最後のコマンドを実行すると、「website」のポインターが各サブモジュールの最新のものに更新される可能性があり、これは望ましくないため、正しくありません。リポジトリにある正しいリビジョンを保持したいと思います。

私が説明しなければならないことの1つは、通常、このサブモジュール内で作業することです。たとえば、次のようになります。

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

git submodule update'master'ブランチを実行すると、すべてのサブモジュールで失われます。

最後に、サブモジュールを操作し、このすべての問題が発生しないpush正しい方法は何ですか？pull

前もって感謝します

4

1 に答える 1

11

git-scm のドキュメントを見て、チームに伝えてください。あなたが見ている現象は、「サブモジュールを含むプロジェクトの複製」セクションで正確に説明されています。

最初に、これらのコミット ハッシュの予想外の反対の結果を示している、観察した初期状態は、親リポジトリでサブモジュールの更新をマージしたが、ローカルでgit diff実行しなかったことを示しています。メイン プロジェクトでサブモジュールの変更をプルダウンするたびgit submodule updateに実行する必要があります。git submodule updateなんで？サブモジュールのポインタ、つまり親リポジトリが の状態と見なすものは、vendor/auth実際にHEADはサブモジュール リポジトリのコミットではありませんvendor/auth。git がサブモジュールの状態をどのように追跡しているかを理解するまでは、少し混乱します。繰り返しになりますが、git-scm のドキュメントは一読の価値があります。

次に、サブモジュールのブランチを意図的にgit submodule update放棄します。これらのドキュメントの「サブモジュールの問題」masterセクションを確認してください。多くの場合 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

では、これらの問題を起こさずにサブモジュールを操作するにはどうすればよいでしょうか? まず、あなた自身とあなたのチームに尋ねてください。本当に必要ですか? サブモジュールは場合によっては強力で便利な機能ですが、サブリポジトリに分割されたアクティブなプロジェクトよりも、サード パーティのライブラリ向けに設計されています。確かにこの方法でそれらを使用できますが、管理オーバーヘッドは、得られる利点を急速に超える可能性があります。リポジトリが非常に大きいか、サブモジュールが完全にモジュール化されていない限り、「単一のリポジトリの方が良いでしょうか?」と尋ねる価値があります。答えが「いいえ」であっても、サブツリーのマージを確認してください。これは、ユース ケースでより成功する可能性があります。

サブモジュールを引き続き使用したい場合は、上記のリンク先のドキュメントと、サブモジュールのワークフローに関する SO や他のサイトの多くの質問と回答を確認してください。それらは、より健全なプロセスを達成するのに役立つはずです。

于 2012-08-22T15:41:24.273 に答える