git - 检查一个 git commit，包括当时的子模块

Question

我们如何检查包含子模块的 git 提交当时的状态？

我们可能想要这样做的一个原因是查看主程序的先前版本，我们需要使用提交时使用的版本中的子模块重建主程序。

鉴于此，我们甚至可以在常规工作流程中使用它:

• 首先使用 git submodule update --remote --merge 更新所有子模块，然后尝试构建以查看程序是否可以使用所有子模块的最新版本。
• 如果成功，我们就完成了。如果它不起作用，那么我们可以转到以前版本的程序，包括。它使用的子模块版本及其工作。
• 然后逐个更新子模块并更改程序以使用它们。

我们可以通过手动查看每个子模块来做到这一点:哪个提交具有适当的时间戳(并希望该程序使用当时最新的版本)。如果我们能看到程序的提交 X 使用了子模块提交 Y，那就更好了。并检查每个子模块的提交。

Answer 1

在这种情况下，您只需要运行 git submodule update --checkout (没有 --merge ，没有 --remote )在 checkout 之前的提交之后。

围绕子模块存在很多混淆。虽然基础实际上相当简单:

• 每个子模块都是自己的 Git 存储库。
• 从子模块中，将“包含”Git 称为 super 项目。
• super 项目记录 URL 和路径——这些是您通常通过运行 git clone 控制或提供的内容—对于 .gitmodules 中的每个子模块文件。
• 同时，当您在 super 项目中进行提交时，此提交在其快照中像往常一样包含所有正常的树和文件，而且对于每个子模块，还包含在 checkout 子模块时要 checkout 的提交 ID。 ¹

这具有将适当的子模块提交“卡住”到每个 super 项目提交中的效果。它是 - 或者最初是 - 用于管理第三方代码，其中子模块本身与 super 项目相比很少更改。

这种模式一点也不灵活，不适合很多人想要使用子模块的方式，也就是让它们保持在某个分支的顶端。因此，子模块增加了更新分支名称的能力，或者被修改并使工作 rebase 和/或 merge 的能力。这些新能力催生了 submodule.<em>name</em>.update配置条目和git submodule update --remote选项。

如果您没有配置任何这些项目，git submodule update alone 将检查当前记录的每个子模块所需的(记录的)子模块提交，即 HEAD , 提交 super 项目。如果您已经配置了其中的一些，您可以使用 git submodule update --checkout覆盖配置并导致 git checkout <em>hash-id</em>在每个子模块中。请注意，添加 --force即使 HEAD 也让 Git 执行此子模块 check out 已经在该入口处。但是由于每个子模块都是它自己的 Git 存储库，因此子模块的 checkout 与它自己的(每个存储库/每个工作树)索引和工作树有自己的交互。²

同样，每个子模块都是它自己的 Git 存储库，这意味着当前 super 项目的子模块可能有它自己的子模块。如果是这样，这也使子模块成为 super 项目，这就是 --recursive 的位置。 flag 进来了。如果你没有嵌套子模块，这些复杂性都不会影响你。

---

¹换句话说， super 项目的索引 对每个子模块都有一个条目。这个索引条目的类型是“gitlink”，它存储了从HEAD读取的SHA-1。在子模块中。这些 gitlink 条目被视为符号链接(symbolic link)和目录之间的一种奇怪的交叉。

²换句话说，如果您手动输入了子模块之一并修改了索引和/或工作树，则 git checkout在 inside 运行该子模块(如果有)可能仍会将您的修改带到新 checkout 的提交中。