Git 交互式 rebase 实战：将后续修改合并到历史提交

背景

在开发过程中，我们经常遇到这样的场景：提交了一个修复（fix），但之后发现遗漏了一些内容，或者有更好的实现方式。如果直接将新改动作为一个独立提交，会让 Git 历史变得零散，不利于代码审查和维护。更好的做法是通过交互式 rebase 将新改动"压缩"进之前的提交中，使历史保持整洁。

本文记录了一次完整的操作过程：将一个深度修改的文件合并回历史上的一个修复提交中，同时解决冲突、跳过空提交，最终得到干净的历史。

场景描述

假设你正在开发一个项目，已经提交了数个关于应用主题的修改：

fix crash when modify the wifi password ------ 修复了密码页面崩溃问题，但只补了缺失的两个属性。
change title to black ------ 将标题改成黑色。
后续又做了大量改进，希望将它们合并到那个修复提交中，而不是单独新增一个提交。

此时工作区中有一个完整的主题配置文件修改，正是所有改进后的最终版本。

目标

将当前工作区中完整的配置文件合并到历史提交 fix crash when modify the wifi password 中，并且不留下任何临时提交。

操作步骤

1. 准备工作

bash 复制代码

git status

确保工作区只有我们需要合并的那个文件被修改，没有其他无关改动。

2. 创建临时提交

由于 rebase 要求工作区干净，我们先将文件提交为一个临时 commit，以便在 rebase 过程中引用它。

bash 复制代码

git add path/to/your/theme.xml
git commit -m "TEMP: full theme fix"

记下这个临时提交的 commit ID（例如 f7c7ef66c8a），后面会用到。

3. 启动交互式 rebase

我们需要停在目标提交上，所以使用目标提交的前一个提交作为 rebase 的起点：

bash 复制代码

git rebase -i <target-commit>^

例如：

bash 复制代码

git rebase -i 9166d99ca70^

这里 ^ 表示目标提交的父提交，这样 9166d99ca70 会出现在编辑器列表中。

4. 标记要修改的提交

在打开的编辑器中，将第一行（即我们要修改的提交）的 pick 改为 edit（或简写 e），其余保持 pick。保存并退出（vim 下 :wq）。

复制代码

edit 9166d99ca70 fix crash when modify the wifi password
pick 34517c1af89 change title to black
...
pick f7c7ef66c8a TEMP: full theme fix

5. 提取临时提交中的文件

Rebase 会停在 edit 标记的提交上。此时工作区干净，但我们需要把最终版本的配置文件从这里开始应用。

使用 git checkout 从临时提交中取出文件：

bash 复制代码

git checkout f7c7ef66c8a -- path/to/your/theme.xml

这个命令会将临时提交中的指定文件复制到当前工作区。

6. 将文件修改并入当前提交

bash 复制代码

git add path/to/your/theme.xml
git commit --amend --no-edit

--amend 表示修改当前提交，--no-edit 保持原提交信息不变。现在当前提交已经包含了完整的新文件。

7. 继续 rebase

bash 复制代码

git rebase --continue

Git 会开始按顺序重放后面的提交。因为我们后面有一个提交也修改了同一个文件，此时极有可能出现冲突。

8. 解决冲突

当冲突发生时，Git 会提示：

复制代码

both modified:   path/to/theme.xml

由于我们已经在前面提交里包含了所有改动，因此应该保留我们 rebase 分支的版本（ours），即当前的完整文件。

bash 复制代码

git checkout --ours -- path/to/your/theme.xml
git add path/to/your/theme.xml
git rebase --continue

这样冲突就被解决了，Git 会继续应用剩余的提交。

9. 跳过空提交

当重放到我们之前创建的临时提交 TEMP: full theme fix 时，因为它的所有改动已经在前面被吸纳，Git 发现这个提交是"空的"（nothing to commit），会停下来提示：

复制代码

The previous cherry-pick is now empty...

此时我们告诉 Git 跳过它：

bash 复制代码

git rebase --skip

这个临时提交会被丢弃，不会出现在最终历史中。

10. 验证结果

bash 复制代码

git log --oneline -8

查看提交历史，应该不再有 TEMP: full theme fix 这个提交，而目标提交 fix crash when modify the wifi password 现在包含了完整的文件改动。

bash 复制代码

git show <new-commit-id>

确认 diff 内容是否符合预期。

注意事项与常见陷阱

rebase 前确保工作区干净
git rebase 不允许未提交的改动。如果不想先手动提交，可以使用 --autostash 参数让 Git 自动 stash 再恢复，但有时会导致文件状态混乱（如本文开头的情况），建议显式创建临时提交。
冲突解决原则

当 rebase 过程中发生冲突时，需要清楚哪个版本是正确的。通常是将后续修改合并到旧提交时，后续的版本（ours）才是完整且最新的，应优先保留。
空提交处理

如果某个被重放的提交已经没有任何新内容（因为其改动早已被包含在前面的提交里），Git 会报冲突或提示 empty，直接 git rebase --skip 跳过即可。
历史重写风险
git rebase -i 会改写历史。如果分支已经推送到远程且与他人协作，操作前务必沟通，推送时需使用 git push --force-with-lease，并确认不会覆盖他人的工作。
备份分支

在进行复杂的 rebase 前，建议创建一个临时备份分支：
bash 复制代码
```
git branch backup-branch
```
操作失误时可以 git reset --hard backup-branch 恢复。

总结

通过交互式 rebase，我们成功将一个独立提交的完整修改压缩进了历史中的修复提交，并移除了中间的临时提交，使提交历史干净、逻辑清晰。这种方法在日常开发中非常实用，尤其适合在代码评审后需要修正历史提交的场景。

整个过程展示了：

如何使用 edit 模式修改历史提交
如何从其他提交中提取文件（git checkout <commit> -- <file>）
如何解决冲突并跳过空提交

掌握这些技能，你将能更自信地维护一个整洁的 Git 提交历史。