git子模块的工作方式 [英] how exactly does git submodule work

问题描述

.gitmodule 文件仅指定模块存储库url。 git submodule 如何知道要下载哪个版本？它似乎总是检查出最新版本。那么，开发人员如何确保主项目和子模块之间的兼容性？ 您的子模块表示为一个特殊的条目，一种特殊的模式（称为 gitlink ，请参阅嵌套git存储库无子模块？）：

（请参阅 Checkout past git submodule commit ）

 新文件模式160000 
索引0000000..4c4c5a2 
  

所以它没有检出最新版本，而是一个特定的SHA1，这样做在 DETACHED HEAD 模式（请参阅 HEAD 子模块附加到实际的 code> HEAD ？。

这并不意味着您无法更新子模块，因为我在子模块的真实性质中解释。

有关子模块的更多信息，以及潜在您为什么不愿使用它们（！）的原因，请阅读清醒的文章，来自 Amber Yust （也在SO

只有一个小提取物，用于踢腿和咯咯（强调我的）：

调用 git子模块update 时，它会在父存储库中为每个子模块查找SHA，进入这些子模块并检出相应的SHA。 >
如果您在常规存储库中签出SHA，情况会如此，这会使子模块进入分离的HEAD状态。

如果您然后然后在子模块中进行更改并提交，Git会高兴地创建提交...并让您仍然使用分离的HEAD。看看这是怎么回事？

假设您合并了一些更多的更改，其中包含另一个子模块更新。如果您尚未将自己的子模块更改为父项目，Git将不会将您在子模块中的新提交视为冲突，如果运行 git子模块更新， c $ c>它会高兴地清除您的提交而不会发出警告，用您刚刚合并的分支中的代替。

我希望你有你的子模块的 reflog 已启用，或者您的终端回滚中仍旧存在旧提交，因为否则，您只是失去了所有您所做的工作。

错误...哎呀。

---

请注意，现在子模块可以跟踪分支的最新情况：请参阅 git submodule tracking latest 。

p>

The .gitmodule file only specifies the module repository url. How does git submodule know which version to download? It seems to be always checking out the latest version. Then, how does developers ensure compatibility between the main project and the sub modules?

解决方案

Your submodule is represented as a special entry with a special mode (called a gitlink, see "Nested git repositories without submodules?"):
(See "Checkout past git submodule commit")

new file mode 160000
index 0000000..4c4c5a2

So it isn't checking out the "LATEST" version, but always a specific SHA1, and it does so in a DETACHED HEAD mode (see "How to make submodule with detached HEAD to be attached to actual HEAD?".

That doesn't mean you can't update a submodule, as I explain in "true nature of submodules".

For more on submodules, and on potentially why you might not want to use them(!), read the sobering article "Why your company shouldn’t use Git submodules", from Amber Yust (also on SO).

Just one small extract, for kicks and giggles (emphasis mine):

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.

Err... "ouch".

---

Note that now a submodule can track the latest from a branch: see "git submodule tracking latest".

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