Git 交互式变基保留合并提交的操作路径

一条功能分支如果曾经合并过子分支，直接执行 git rebase -i main 往往会把这段历史按普通提交重新播放，原来的分叉与汇合关系也会消失。想在整理提交顺序、修改说明或压缩提交的同时继续保留合并拓扑，关键入口是 --rebase-merges：Git 会把合并关系展开成一份包含 label、reset 与 merge 的交互计划，再按这份计划重建 merge 节点。

官方文档：https://git-scm.com/docs/git-rebase

先说清一个容易误解的边界：这里“保留”的是分支拓扑和合并语义，不是保留旧 merge commit 的对象 ID。变基后的父提交发生变化，普通提交和合并提交都会成为新对象；merge -C 复用的是原合并说明，而不是旧对象本身。

一、先确认当前历史确实包含需要保留的 merge

进入仓库后，先切到待整理的 topic 分支，再查看完整图谱。操作路径是“仓库目录 → topic 分支 → 图形日志”，不要一上来就执行变基。只有在日志里看到分叉后重新汇合的 merge 节点，才需要使用本文的路径。

# 切到待整理的分支
git switch topic

# 确认工作区干净，避免未提交修改混入变基过程
git status --short

# 查看分支、提交说明和合并拓扑
git log --graph --oneline --decorate --all

如果 git status --short 没有输出，说明工作区与暂存区都没有待处理修改。图形日志中，主线旁边出现支线并在后续节点汇合，说明这段历史包含合并提交。若只是完全线性的提交序列，普通交互式变基已经足够。

二、创建明确的回退点，而不是只依赖 ORIG_HEAD

官方文档说明，变基开始时 ORIG_HEAD 会指向原分支顶端，但后续某些命令也可能改写它。更稳妥的做法是在执行历史改写前创建命名备份分支。操作路径是“当前 topic 分支 → 新建 backup/topic-before-rebase → 再次查看引用”。

# 固定变基前的分支顶端，名称可按团队规范调整
git branch backup/topic-before-rebase

# 确认 topic 和备份分支当前指向同一提交
git log -1 --oneline topic
git log -1 --oneline backup/topic-before-rebase

两条日志显示相同的短哈希和提交说明，表示回退点已经建立。共享分支还应提前通知协作者暂停推送，因为后面的操作会改写提交历史。

三、用 --rebase-merges 打开交互计划

准备完成后，在 topic 分支上把 main 作为上游打开交互计划：

# -i 打开交互计划，--rebase-merges 要求 Git 重建合并拓扑
git rebase -i --rebase-merges main

也可写成 git rebase -i -r main。命令执行后，Git 会调用配置的序列编辑器。与普通 -i 只列出一串 pick 不同，这份 todo 通常还会出现三类结构行：

• label feature：给当前提交位置建立临时标签，供后续结构命令引用。
• reset base：把重放位置切回某个标签，开始重建另一条支线。
• merge -C M feature：把标记为 feature 的支线重新合并，并复用旧 merge commit M 的提交说明。

如果希望在重建合并提交时重新编辑说明，可把 -C 改成 -c。这不会改变“重建一个新 merge commit”的事实，只是额外打开提交说明编辑器。

四、编辑 todo 时把结构行当作边界

稳妥的编辑原则是：先看懂每个 label → reset → merge 形成的结构块，只在对应块内部调整普通提交。把某个 pick 改成 reword 可修改说明，改成 squash 可并入前一个提交；但不要随意删除 label，也不要把 merge 移到它引用的标签之前。

# 普通提交可以在所属支线内改为 reword、edit、squash
pick A feature: add parser
label feature
reset base
pick B topic: wire parser
merge -C M feature

保存并关闭编辑器后，Git 才会真正开始重放。可见的正确状态是：todo 不再停留在编辑器中，Git 逐个处理提交；若没有冲突，流程会自动结束。即使看到成功提示，也只代表命令流程完成，最终拓扑仍要在后面的日志检查中确认。

五、遇到冲突时按“查看—解决—暂存—继续”处理

保留合并的变基既可能在重放普通提交时冲突，也可能在重建 merge 节点时冲突。Git 停下后，不要再次运行最初的 rebase 命令。正确路径是“查看当前状态 → 定位冲突文件 → 完成编辑 → 标记已解决 → 继续”。

# 查看当前停在哪一步以及有哪些未合并文件
git status

# 查看正在重放的补丁，帮助判断变更意图
git rebase --show-current-patch

# 编辑完成后，把已解决文件加入暂存区
git add path/to/resolved-file

# 继续执行剩余的交互计划
git rebase --continue

使用 merge 后端处理冲突时，提示中的 ours 指向“已经变基到上游后的当前序列”，theirs 指向正在重放的原工作分支提交，和日常 merge 场景中的直觉可能相反。因此不要只凭名称选择整侧内容，应结合差异和业务含义处理。

如果发现上游选错、todo 结构改乱，或者冲突规模超出预期，直接执行：

# 取消整个变基，并把 HEAD 与工作区恢复到开始前的分支状态
git rebase --abort

--abort 会完整回到起点；--quit 只停止变基，不负责把 HEAD、索引和工作区恢复原状，两者不要混用。即使执行了 --abort，前面创建的备份分支仍会保留。

六、确认“拓扑保留、对象已更新”

变基完成后先不要推送。再次查看图形日志，操作路径是“topic 分支 → 图形日志 → 对照 backup/topic-before-rebase”。你应该看到新的普通提交哈希，也应看到支线重新汇入主线的 merge 节点。

# 查看变基后的整体拓扑
git log --graph --oneline --decorate --all

# 对比新旧分支各自相对 main 的最终文件变化
git diff --stat main...backup/topic-before-rebase
git diff --stat main...topic

# 运行项目自身的测试命令；按实际技术栈替换
go test ./...

判断成功不能只看提交数量。至少核对三件事：新的图谱仍有预期的分叉和 merge 汇合点；最终文件差异符合变基前的业务结果；项目测试通过。若图谱变成直线，通常意味着执行的是普通 git rebase -i，或者编辑 todo 时破坏了结构行。

七、更新远端时使用 force-with-lease

本地核对无误且团队确认可以改写远端历史后，再更新 topic。因为新旧提交对象不同，普通 push 通常会被拒绝；推荐使用带租约的强制推送：

# 仅在远端仍是本地预期状态时改写 topic，降低覆盖他人提交的风险
git push --force-with-lease origin topic

--force-with-lease 会在远端分支已经被其他人更新时拒绝覆盖，比裸 --force 多一道保护。若推送被拒绝，应先 git fetch origin 查看远端新增内容，再与协作者决定如何整合，不要立即改用裸强推。

操作路径速记

1. 切到 topic，确认工作区干净并查看 --graph。
2. 创建 backup/topic-before-rebase 作为明确回退点。
3. 执行 git rebase -i --rebase-merges main。
4. 保留 label、reset、merge 结构，只在正确支线块内整理普通提交。
5. 冲突解决后 git add 并 git rebase --continue；需要放弃时使用 --abort。
6. 核对图谱、最终差异与测试，再用 git push --force-with-lease 更新远端。

整条路径的核心不是让旧 merge commit 原封不动留下来，而是让 Git 在新的上游和新的提交对象上重新创建同样有意义的分支结构。理解这一点，就能接受哈希变化，并把验证重点放在拓扑、内容和可回退性上。