Git子模块工作流程问题 [英] Git submodules workflow issues

问题描述

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

  [submodulevendor / api] 
 path = vendor / api 
 url = [e-mail] .com：api 
 [submodulevendor / auth] 
 path = vendor / auth 
 url = [e-mail]：auth 
 [submodulevendor / tools] 
 path = vendor / tools 
 url = [e-mail]：tools 
  

我们已经正确检出了我们的主要存储库'网站'。现在我的一位同事做了一个推动，然后我 git pull; git status ：

 ＃分支大师
＃已更改但未更新：
＃（使用git add< file> ...更新将要提交的内容）
＃（使用git checkout  - < file> ...放弃工作目录中的更改） 
＃
＃modified：vendor / api（new commitits）
＃modified：vendor / auth（new commitits）
＃modified：vendor / tools（new commitits）
＃
未提交更改（使用git add和/或git commit -a）
 
 mcfly @ future：〜/ projects / website $ git diff 
 
 diff --git a / vendor / api b / vendor / api 
索引41795fc..b582d80 160000 
 --- a / vendor / api 
 +++ b / vendor / api 
 @@ -1 +1 @@ 
  - 子项目提交41795fc4dde464d633f4c0f01eebb6ab1ad55582 
 +子项目提交b582d802419b0ee7bc3959e7623fec0b94680269 
 diff --git a / vendor / auth b / vendor / auth 
 index a00369b..4599a71 160000 
 --- a / vendor / auth 
 +++ b / vendor / auth 
 @@ -1 +1 @@ 
  - 子项目提交a00369bf29f14c761ce71 f7b95aa1e9c107fb2ed 
 +子项目提交4599a7179c9b7ca4afa610a15ffa4a8fc6ebf911 
 diff --git a / vendor / tools b / vendor / tools 
 index f966744..c678cf6 160000 
 --- a / vendor / tools 
 +++ b / vendor / tools 
 @@ -1 +1 @@ 
  - 子项目提交f966744359510656b492ae3091288664cdb1410b 
 +子项目提交c678cf6f599fc450e312f0459ffe74e593f5890f 
  

那个 git diff 有什么问题？问题是每个子模块的新提交比旧的提交更旧，而不是将被覆盖的提交。这不是我们想要的，因为存储库正确指向 41795fc4dde464d633f4c0f01eebb6ab1ad55582 ， a00369bf29f14c761ce71f7b95aa1e9c107fb2ed 和 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 $ echolorem ipsum>> example.file 
 mcfly @ future：〜/ projects / website / vendor / api $ git add example.file; git push 
  

当我们做一个 git submodule update 'master'分支在每个子模块上丢失。

最后，执行 push 的正确方法是什么>， pull 并且使用子模块并且没有所有这些问题？



预先感谢您

解决方案

查看 git-scm documention 并将它传递给你的团队。你看到的现象在使用子模块克隆项目部分。

首先，观察初始状态，其中 git diff 显示这些提交哈希的结果意外相反，表示您已合并父库中的子模块更新，但未在本地运行 git子模块更新。每次在主项目中下拉子模块更改时，都必须运行 git子模块更新。为什么？子模块的指针，即父级存储库认为是 vendor / auth 的状态，实际上并不是 HEAD 子模块存储库 vendor / auth 的提交。直到你了解git如何跟踪子模块状态，这有点令人困惑。同样， git-scm文档值得一读。

其次， git子模块更新放弃主通过设计在子模块上进行分支。查看子模块问题这些文档的一部分。手册页，就像git经常使用的那样，告诉我们我们需要知道什么：

  update 
更新已注册的子模块，即克隆缺少的子模块并检出包含存储库的索引中指定的提交。这将
使子模块HEAD分离，除非指定--rebase或--merge或者将子模块$ name.update设置为rebase，merge或none。无
可以通过指定--checkout来覆盖。 
  

您将子模块放在'detached HEAD '状态，每当你发出 git子模块更新不带参数时。

所以你如何使用子模块有这些问题？首先，问问你自己和你的团队：我们真的需要他们吗？子模块在某些情况下是一个强大且有用的功能，但它们设计的更多的是第三方库，而不是将活动项目分解为子库。你当然可以这样使用它们，但管理开销可能会迅速超过你获得的任何好处。除非您的存储库非常大，否则您的子模块是完全模块化的，所以值得问一下我们是否更适合使用单个存储库？ 即使答案是否，请查看子树合并，，这可能对您的用例更成功。

如果您仍想使用子模块，请查看上面链接的文档，以及许多问题和答案在SO和其他网站上介绍子模块工作流程。他们应该帮助你实现一个更加安全的过程。

We are having a lot of problems recently with our Git repositories. We are users of git submodules for a total of 4 shared repositories between our applications.

For example, repository 'website' has a total of 3 submodules.

[submodule "vendor/api"]
    path = vendor/api
    url = [e-mail]:api
[submodule "vendor/auth"]
    path = vendor/auth
    url = [e-mail]:auth
[submodule "vendor/tools"]
    path = vendor/tools
    url = [e-mail]:tools

We have checked out correctly our main repository 'website'. Now one of my co-workers have done a push, then I 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

What's the problem with that git diff? The problem is that the new commits for each submodule are OLDER than the ones that will be overwritten. That's not what we want because on the repository is pointing correctly to 41795fc4dde464d633f4c0f01eebb6ab1ad55582, a00369bf29f14c761ce71f7b95aa1e9c107fb2ed and f966744359510656b492ae3091288664cdb1410b and if we add this modifications to our next commit we will probably brake the things. I don't know why its getting the oldest revision and not the newest.

I have tried to solve this by myself but with no success:

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

Doing the last command it's not correct because we will probably update the pointer of 'website' to the newest of each submodule and we don't want this. We want to preserve the correct revision that it's on the repository.

One of the things that I've to explain that we usually work inside this submodules, for example:

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

When we do a git submodule update the 'master' branch is lost on every submodule.

Finally, what si the correct way of doing the push, pull and working with submodules and not having all this problems?

Thank you in advance

解决方案

Take a look at the git-scm documention and pass it around to your team. The phenomenon you're seeing is exactly described in the "Cloning a Project with Submodules" section.

First, the initial state you observed, where git diff shows unexpectedly opposite results for those commit hashes, indicates you merged a submodule update in the parent repo, but didn't run git submodule update locally. You have to run git submodule update every time you pull down a submodule change in the main project. Why? The submodule's pointer, i.e. what the parent repository thinks is the state of vendor/auth, isn't actually the HEAD commit of the submodule repository vendor/auth. It's a little confusing until you understand how git is tracking the submodule states. Again, the git-scm documentation is worth a read.

Second, git submodule update abandons the master branch on the submodule by design. Check out the "Issues with submodules" section of those docs. The man page, as is often true with git, tells us what we need to know:

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.

You're putting your submodules in 'detached HEAD' state every time you issue git submodule update without argument.

So how do you work with submodules without having these problems? First, ask yourself and your team: Do we really need them? Submodules are a powerful and useful feature in some cases, but they were designed more for 3rd party libraries than active projects fractured into sub-repositories. You can certainly use them this way, but the management overhead might rapidly exceed whatever benefits you're getting. Unless your repository is quite large, or your submodules are completely modular, it's worth asking "Would we be better off with a single repository?" Even if the answer is "no", check out subtree merging, which might be more successful for your use case.

If you'd still like to use submodules, check out the docs linked above, as well as the many questions and answers on SO and other sites about submodule workflows. They should help you achieve a saner process.

这篇关于Git子模块工作流程问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！