我们如何检查包含子模块的git提交，就像当时那样？
我们可能想要这个的一个原因是查看我们需要使用提交时使用的版本中的子模块重建它的主程序的先前版本。
鉴于此，我们甚至可以在常规工作流程中使用它：
git submodule update --remote --merge更新所有子模块，然后尝试构建以查看该程序是否可以使用所有子模块的最新版本。 我们可以通过手动查看每个子模块来实现：哪个提交具有适当的时间戳（并希望程序使用最新版本的版本）。如果我们可以看到使用子模块提交Y的程序的提交X会更好。并检查每个子模块的那些。
答案 0 :(得分：3)
在这种情况下，您只需在签出之前的提交后运行git submodule update --checkout（无--merge，无--remote）。
子模块周围存在很多混淆。实际上，基础知识非常简单：
git clone来控制或提供的内容 - 为.gitmodules文件中的每个子模块。这有＆＃34;冷冻＆＃34;适当的子模块提交到每个超级项目提交。它最初是用于管理第三方代码，其中子模块本身与超级项目相比很少变化。
这个模型并不灵活，并且不适合许多人想要使用子模块的方式，这是将它们保持在某个分支的顶端。因此，子模块增加了更新分支名称或进行工作并使工作重新定位和/或合并的能力。这些新功能产生了submodule.name.update配置条目和git submodule update --remote选项。
如果您尚未配置任何这些项，git submodule update将仅检查当前记录的每个子模块的所需（记录）子模块提交，即{{1}超级项目的提交。如果 配置了其中一些，则可以使用HEAD覆盖配置并在每个子模块中生成git submodule update --checkout。请注意，即使git checkout hash-id已经在该条目，添加--force也会使Git执行此子模块检出。但由于每个子模块都是自己的Git存储库，因此子模块的checkout与其自己的（每个存储库/每个工作树）索引和工作树有自己的交互。 2 < / p>
同样，每个子模块都是自己的Git存储库，这意味着当前超级项目的子模块可能有自己的子模块。如果是这样，这使得子模块也成为一个超级项目，这就是HEAD标志的来源。如果你没有嵌套子模块，这种复杂性都不会影响你。
1 换句话说，超级项目的索引每个子模块都有一个条目。此索引条目的类型是＆＃34; gitlink＆＃34;，它将来自--recursive的SHA-1读取存储在子模块中。这些gitlink条目被视为符号链接和目录之间的奇怪交叉。
2 换句话说，如果您手动输入了其中一个子模块并修改了索引和/或工作树，则HEAD在中运行该子模块（如果有的话）仍然可以将您的修改带入新的签出提交。