在提交中恢复对子模块的更改 发生了什么

如何解决在提交中恢复对子模块的更改 发生了什么

在提交主存储库中的文件时，我不小心更改了 2 个子模块的状态。这可能是在 rebase 时发生的，但我不确定我是否不了解 子模块。

有没有办法编辑提交并撤消对子模块的更改而不撤消对文件的良好更改？我熟悉使用 git rebase -i 和 git commit --amend 在常规项目中执行此操作，但我不知道如何为 子模块 执行此操作。

这是混乱的提交：https://github.com/PiRK/ElectrumABC/commit/f1bf0893c1becc01b8191c4a8c37eafd26c2a29d 我需要 contrib/tor 再次指向 it's remote repository 中的 7ce4ae344 commot，以及 contrib/ssl 指向回 https://github.com/openssl/openssl/

中的 fd78df59b0

我很高兴添加一个仅修复两个子模块的提交，或者通过编辑我的错误提交来更改历史记录（这最好，因为它避免了几次提交的不一致状态).

解决方法

要添加修复两个子模块的新提交：

1. 查看以“错误”提交结尾的分支顶端的超级项目。如有必要，运行 git submodule update --init 以克隆两个子模块。

2. 输入每个子模块并通过您列出的两个原始哈希 ID 检查正确提交：

   (cd contrib/tor && git checkout 7ce4ae344)
   (cd contrib/ssl && git checkout fd78df59b0)
   

   （如果您愿意，可以使用 git switch --detach 而不是 git checkout；效果没有区别。）

3. git status 现在将显示“未暂存以进行提交的更改”部分中的两个子模块。将它们添加到 Git 的索引中：

   git add contrib/tor contrib/ssl
   

   现在 git status 将在“为提交而暂存的更改”部分中显示它们。

4. 进行新的提交。

可以使用 git rebase 等将一些旧的提交替换为新的和改进的提交；在第 4 步中使用 git commit --amend 而不是 git commit 将仅替换一个 tip 提交；但总的来说，用新的和改进的提交替换旧的错误提交会给已经发现错误提交的其他人带来麻烦，而且它几乎没有增加价值。如果您非常确定没有其他人发现错误的提交，请随意做额外的工作以使其看起来没有错误进入，但没有人会真正关心。 ?

发生了什么

Git 存储库中的

每次提交都代表该存储库中所有文件的确切状态。也就是说，每个提交都包含每个文件的完整快照。子模块“文件”只是存储在某个路径名中的提交哈希 ID。这是对超级项目 Git 的指令：当这个提交被检出时，这些子模块路径和哈希 ID 都在 Git 的索引中，git submodule update 应进入每个命名的子模块并运行 {{1} } 在指定的提交上。

因此，每个包含某个子模块的提交实际上只有一个路径（例如 git checkout）和一个原始哈希 ID。该哈希 ID 最好是存在于通过克隆存储在 contrib/tor 或 .gitmodules 中的任何 path 的克隆中的某个提交的哈希 ID，如果子模块尚未克隆；或者，最好是该克隆中存在的某些提交的哈希 ID，或者如果超级项目 Git 进入子模块 Git 存储库并运行 .git/config，则将存在于该克隆中。

这就是子模块的全部内容：指令。输入一些other Git 存储库并运行git fetch。要更新指令，您只需自己输入该存储库，运行给定的 git checkout，返回超级项目，然后运行 ​​git checkout。这会更新 Git 的 index，这是您下一次提交的来源。所以 next 提交现在将包含另一个哈希 ID。

请注意，子模块不使用分支名称。它们总是由原始哈希 ID 完成。您可以为它们设置分支名称，但这些（至​​少目前）仅用于特殊的 git add 选项（特别是 git submodule update）。因为大多数 Git 命令使用原始散列 ID，我建议坚持使用原始散列 ID 方法，至少在您熟悉它并遇到 git submodule update --remote 变得有用的特殊情况之前：请记住，即使 git submodule update --remote 仍然通过哈希 ID 起作用，它只是从某个棘手的地方获取哈希 ID。