Git 子模块工作流程问题

最近，我们的 Git 存储库遇到了很多问题。我们是应用程序之间总共 4 个共享存储库的 git 子模块的用户。

例如，存储库“网站”共有 3 个子模块。

[submodule "vendor/api"]
    path = vendor/api
    url = [email protected] /cdn-cgi/l/email-protection:api
[submodule "vendor/auth"]
    path = vendor/auth
    url = [email protected] /cdn-cgi/l/email-protection:auth
[submodule "vendor/tools"]
    path = vendor/tools
    url = [email protected] /cdn-cgi/l/email-protection:tools

我们已经正确检查了我们的主存储库“网站”。现在我的一位同事做了推动，然后我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 and f966744359510656b492ae3091288664cdb1410b如果我们将这些修改添加到下一次提交中，我们可能会阻止这些事情。我不知道为什么它得到的是最旧的修订版而不是最新的修订版。

我尝试自己解决这个问题，但没有成功：

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

执行最后一个命令是不正确的，因为我们可能会将“网站”的指针更新为每个子模块的最新指针，而我们不希望这样做。我们希望保留存储库中的正确版本。

我必须解释的一件事是我们通常在这个子模块中工作，例如：

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并使用子模块并且没有所有这些问题？

先感谢您

看看git-scm 文档 http://git-scm.com/book/en/Git-Tools-Submodules并将其传递给您的团队。您所看到的现象在“克隆带有子模块的项目” http://git-scm.com/book/en/Git-Tools-Submodules#Cloning-a-Project-with-Submodules部分。

首先，您观察到的初始状态，其中git diff显示这些提交哈希值的意外相反结果，表示您在父存储库中合并了子模块更新，但未运行git submodule update本地。你必须跑git submodule update每次您在主项目中下拉子模块更改时。为什么？子模块的指针，即父存储库认为的状态vendor/auth，实际上不是HEAD子模块存储库的提交vendor/auth。在您了解 git 如何跟踪子模块状态之前，这有点令人困惑。再次，git-scm 文档 http://git-scm.com/book/en/Git-Tools-Submodules#Cloning-a-Project-with-Submodules值得一读。

Second, git submodule update放弃了master按设计在子模块上分支。查看“子模块的问题” http://git-scm.com/book/en/Git-Tools-Submodules#Issues-with-Submodules这些文档的部分。与 git 一样，手册页告诉我们需要了解的内容：

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没有争论。

那么如何使用子模块而不出现这些问题呢？首先，问问你自己和你的团队：我们真的需要它们吗？在某些情况下，子模块是一个强大且有用的功能，但它们更多地是为第三方库设计的，而不是分解为子存储库的活动项目。您当然可以通过这种方式使用它们，但管理开销可能会很快超过您所获得的任何好处。除非您的存储库非常大，或者您的子模块完全模块化，否则值得一问“使用单一存储库会更好吗？” https://softwareengineering.stackexchange.com/q/161293/57052即使答案是否定的，请查看子树合并， http://git-scm.com/book/en/Git-Tools-Subtree-Merging这对于您的用例来说可能会更成功。

如果您仍然想使用子模块，请查看the docs http://git-scm.com/book/en/Git-Tools-Submodules#Issues-with-Submodules上面链接以及许多问题 https://stackoverflow.com/questions/1596822/git-submodules-workflow and answers https://stackoverflow.com/a/1979194/877115在 SO 和其他有关子模块工作流程的网站上。他们应该帮助您实现更明智的流程。