Git子模块更新

Question

我不清楚以下内容的含义(来自 Git submodule update 文档):

...will make the submodules HEAD be detached, unless --rebase or --merge is specified...

--rebase/--merge 是如何改变的？

我的主要用例是拥有一堆中央存储库，我将通过子模块将其嵌入到其他存储库中。我希望能够改进这些中央存储库，可以直接在它们的原始位置，也可以从它们的嵌入存储库(通过子模块使用它们的存储库)中改进。

• 在这些子模块中，我是否可以像在常规存储库中一样创建分支/修改并使用推/pull ，或者有什么需要注意的地方吗？
• 我如何将子模块引用的提交从说(标记)1.0 推进到 1.1(即使原始存储库的头部已经在 2.0)，或者选择使用哪个分支的提交？

Answer 1

这GitPro page确实很好地总结了 git 子模块更新的结果

When you run git submodule update, it checks out the specific version of the project, but not within a branch. This is called having a detached head — it means the HEAD file points directly to a commit, not to a symbolic reference.
The issue is that you generally don’t want to work in a detached head environment, because it’s easy to lose changes.
If you do an initial submodule update, commit in that submodule directory without creating a branch to work in, and then run git submodule update again from the superproject without committing in the meantime, Git will overwrite your changes without telling you. Technically you won’t lose the work, but you won’t have a branch pointing to it, so it will be somewhat difficult to retrieve.

---

注意 2013 年 3 月:

如“git submodule tracking latest”中所述，子模块现在 (git1.8.2) 可以跟踪分支。

# add submodule to track master branch
git submodule add -b master [URL to Git repo];

# update your submodule
git submodule update --remote 
# or (with rebase)
git submodule update --rebase --remote

参见“git submodule update --remote vs git pull”。

MindTooth的 answer说明手动更新(没有本地配置):

git submodule -q foreach git pull -q origin master

在这两种情况下，这将更改子模块引用( gitlink ，a special entry in the parent repo index)，您将需要从主仓库添加、提交和推送所述引用。< br/>下次您克隆该父存储库时，它将填充子模块以反射(reflect)那些新的 SHA1 引用。

此答案的其余部分详细介绍了经典的子模块功能(引用固定提交，这是子模块概念背后的全部 Gist )。

---

To avoid this issue, create a branch when you work in a submodule directory with git checkout -b work or something equivalent. When you do the submodule update a second time, it will still revert your work, but at least you have a pointer to get back to.

Switching branches with submodules in them can also be tricky. If you create a new branch, add a submodule there, and then switch back to a branch without that submodule, you still have the submodule directory as an untracked directory:

---

所以，回答你的问题:

can I create branches/modifications and use push/pull just like I would in regular repos, or are there things to be cautious about?

您可以创建分支并推送修改。

警告(来自 Git Submodule Tutorial):始终在发布(推送)更改到引用它的 super 项目之前发布(推送)子模块更改。如果您忘记发布子模块更改，其他人将无法克隆存储库。

how would I advance the submodule referenced commit from say (tagged) 1.0 to 1.1 (even though the head of the original repo is already at 2.0)

页面“Understanding Submodules”可以提供帮助

Git submodules are implemented using two moving parts:

• the .gitmodules file and
• a special kind of tree object.

这些一起对特定存储库的特定修订进行三角测量，该修订已 check out 到项目中的特定位置。

---

来自git submodule page

you cannot modify the contents of the submodule from within the main project

100% 正确:您不能修改子模块，只能引用它的一个提交。

这就是为什么当您从主项目中修改子模块时，您:

• 需要在 子模块(上游模块)内提交和推送
• 然后进入你的主项目，并重新提交(为了让该主项目引用你刚刚创建和推送的新子模块提交)

子模块使您能够拥有一个 component-based approach 开发，其中主项目仅引用其他组件的特定提交(此处为“其他 Git 存储库声明为子模块”)。

子模块是另一个不受主项目开发周期约束的 Git 存储库的标记(提交):它(“其他”Git 存储库)可以独立发展。
由主项目从另一个 repo 中选择它需要的任何提交。

但是，如果您想出于方便，直接从您的主项目修改其中一个子模块，Git 允许您这样做，前提是您首先将这些子模块修改发布到其原始 Git 存储库，然后然后引用所述子模块的新版本提交您的主项目。

但主要思想仍然是:引用特定组件:

• 有自己的生命周期
• 有自己的一套标签
• 有自己的发展

您在主项目中引用的特定提交列表定义了您的 configuration (这就是配置管理的全部内容，仅包含 Version Control System)

如果一个组件真的可以作为您的主项目同时开发(因为对主项目的任何修改都将涉及修改子目录，反之亦然)，那么它会不再是一个“子模块”，而是一个子树 merge (也出现在问题 Transferring legacy code base from cvs to distributed repository 中)，将两个 Git 存储库的历史链接在一起。

这有助于理解 Git 子模块的真正本质吗？