git - git子模块究竟是如何工作的

Question

.gitmodule 文件仅指定模块存储库 url。 git submodule 如何知道要下载哪个版本？它似乎总是检查最新版本。那么，开发者如何保证主工程与子模块的兼容性呢？

Answer 1

您的子模块表示为具有特殊模式的特殊条目(称为 gitlink ，请参阅“Nested git repositories without submodules?”):
(参见“Checkout past git submodule commit”)

new file mode 160000
index 0000000..4c4c5a2

所以它不是检查“最新”版本，而是始终检查特定的 SHA1，并且它在 DETACHED HEAD mode 中检查(参见“How to make submodule with detached HEAD to be attached to actual HEAD?”。

这并不意味着您不能更新子模块，正如我在“true nature of submodules”中解释的那样。

有关子模块的更多信息，以及您可能不想使用它们的潜在原因(!)，请阅读来自 Why your company shouldn’t use Git submodules 的发人深省的文章“Amber Yust” (还有 on SO )。

只是一个小片段，用于踢腿和咯咯笑(强调我的):

When you invoke git submodule update it looks in the parent repository for a SHA for each submodule, goes into those submodules, and checks out the corresponding SHAs.
As would be the case if you checked out a SHA in a regular repository, this puts the submodule into a detached HEAD state.

If you then make changes in the submodule and commit then, Git will happily create the commit… and leave you still with a detached HEAD. See where this is going yet?

Say you merge in some more changes which happen to include another submodule update. If you haven’t committed your own submodule change into the parent project yet, Git won’t consider your new commit in the submodule as a conflict, and if you run git submodule update it will happily wipe out your commit without warning, replacing it with that from the branch you just merged in.

I hope you had your submodule’s reflog enabled or still have the old commit in your terminal scrollback, because otherwise, you just lost all that work you did.

呃……“哎哟”。

---

请注意，现在子模块可以跟踪分支的最新信息:请参阅“git submodule tracking latest”。