.gitmodule
文件仅指定模块存储库URL。 git submodule
如何知道要下载哪个版本?它似乎总是检查出最新版本。那么,开发人员如何确保主项目和子模块之间的兼容性?
答案 0 :(得分:25)
您的子模块表示为具有特殊模式的特殊条目(称为 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)。
只有一个小提取物,用于踢腿和咯咯笑(强调我的):
当您调用
git submodule update
时,它会在父存储库中查找每个子模块的SHA,进入这些子模块,并检出相应的SHA。 如果您在常规存储库中检出SHA,则会将子模块置于分离的HEAD状态。如果您随后在子模块中进行更改并提交,Git将很乐意创建提交...并让您仍然使用分离的HEAD。看看它到底在哪里?
假设您合并了一些恰好包含另一个子模块更新的更改。如果您还没有将自己的子模块更改提交到父项目中,Git将不会将子模块中的新提交视为冲突,而如果您运行
git submodule update
它将很乐意消除您的提交在没有警告的情况下,将其替换为刚刚合并的分支。我希望您的子模块
reflog
已启用,或者您的终端回滚中仍有旧提交,,因为否则,您刚刚丢失了所做的所有工作。
呃......“哎哟”。
请注意,现在子模块可以跟踪分支中的最新信息:请参阅“git submodule tracking latest”。