存在合并冲突时使用 git rebase 修改提交消息

Question

有大量关于如何使用 git rebase 修改旧提交消息的优秀网络指南。 就我而言，这是至关重要的，因为钩子不允许我在不更改消息的情况下进行远程推送。 然而，我见过的指南似乎假设可以直接完成变基，而无需 需要解决冲突。 然而，我发现自己陷入了一个奇怪的第 22 条军规，如下所示：

1. 我可以在 git 编辑器中重写提交消息并使用 git rebase --交互式
2. rebase 失败，因为存在合并冲突。
3. 我被要求解决冲突，我做到了。
4. 变基成功。
5. 显然错误的提交消息没有被追溯纠正，所以我需要纠正它。
6. 我再次变基以更改提交消息。
7. 第二次变基重新审视有合并冲突的有问题的提交，所以我做了 没有任何进展。

基本上看起来是这样的： 如果不更改提交消息，我无法远程推送。 如果不重新调整该提交，我就无法更改提交消息。 如果不先解决合并冲突，我就无法重新定位该提交。 我现在必须再次重新调整该提交以更改提交消息。 但我已经逆转了，因为我现在重新引入了以前的合并冲突 解决了。

我尝试重写提交消息，保存消息并修复合并冲突。

Answer 1

显然错误的提交消息没有被追溯纠正，所以我需要纠正它。

实际上，情况不应该是这样：当您成功完成变基时，即使涉及解决冲突，您所做的更改（包括修改提交消息）也已经成为新的变基提交历史记录的一部分。因此，仅仅为了修改提交消息就不需要第二次变基。

使用

git rebase -i $(git merge-base main HEAD)

开始交互式变基（假设

main

是您要变基的分支）。这将在您的分支和

main

的合并基础上启动变基。这是您的分支与

main

分叉的点，也是您要开始变基的点。

在交互式变基列表中，选择

reword

所需的提交。 继续进行变基操作。如果任何提交中出现冲突，请解决冲突，然后继续变基。 一旦您到达想要重写的提交，Git 将暂停并允许您更改提交消息。

如果在变基过程中发生冲突，Git 会暂停并允许您解决它们。解决每个冲突后，您通常会

git add

已解决的文件，然后

git rebase --continue

继续进行变基过程。
关键点是，一旦解决冲突并继续，该冲突的已解决状态就是变基形成的新提交的一部分。

解决冲突并重写提交后，一旦完成变基过程（

git rebase --continue

直到完成），您的分支的提交历史记录将被重写。它现在包括修改后的提交消息和您执行的任何冲突解决方案。
不需要仅仅为了更改提交消息而进行第二次变基，因为这些更改已经是重写历史记录的一部分。

如果您对更改（修改的消息和冲突解决方案）感到满意，您可以将这些更改推送到远程存储库。如果您重写了历史记录，这可能需要强制推送（使用

git push --force-with-lease

或 Git 2.30+；

git push --force-if-includes

）。

 ┌───────────────────────────────────────────────────────────┐
 │ Your Local Branch                                         │
 │ ┌───────────────────┐  ┌────────┐  ┌────────┐  ┌────────┐ │
 │ │ Merge-Base        │─▶│Commit 2│─▶│Commit 3│─▶│Commit 4│ │
 │ │ (Common Ancestor) │  └────────┘  └────────┘  └────────┘ │
 └───────────────────────────────────────────────────────────┘
       │
       │ Start Interactive Rebase at Merge-Base
       │
       │ Proceed with rewording and conflict resolution ...
       │
       └─── Force-Push to Remote Repository (if necessary)