Git 交互式 rebase 拆分提交的操作清单

一个提交里同时混入“功能代码”和“文档修正”，准备提合并请求时通常需要拆开。Git 交互式 rebase 的正确做法不是直接改历史文本，而是把目标提交停在 edit 状态，取回它的改动，再按逻辑边界重新暂存和提交。下面这份清单只覆盖“拆分已有提交”，不展开成完整的 Git 入门教程。

官方地址：https://git-scm.com/docs/git-rebase

记住一条主线：rebase -i 负责暂停，reset HEAD^ 负责取回，add -p 或按文件暂存负责切分，rebase --continue 负责接回后续历史。

先把要拆的提交和工作区对齐

交互式 rebase 会重写提交对象。开始前先确认自己位于目标分支，并把无关的工作区修改处理掉，否则这些修改可能和待拆内容混在一起。

# 查看当前分支、工作区和最近提交，先确认目标提交的位置
git status
git log --oneline --decorate -n 5

# 如果工作区有暂时不能提交的改动，先用 stash 隔离它们
git stash push -m "暂存 rebase 前的无关修改"

例如最近三条提交中，第二条同时包含“增加导出字段”和“更新 README”，就可以把它作为目标。不要把已经推送且有其他人继续开发的公共分支直接重写；这类操作需要先和协作者约定新的提交历史。

在交互式待办编辑器中标记 edit

从目标提交开始，到当前分支顶端一共涉及几条提交，就把范围写进 HEAD~N。例如目标在最近三条中：

# 打开最近三条提交的交互式待办清单
git rebase -i HEAD~3

编辑器会显示类似下面的待办内容。这里的文本是操作示意，不是某个仓库的运行截图：

edit 7c31a2e 增加导出字段并更新说明
pick 2f8d9c0 修正接口返回示例
pick 94a1b7d 调整测试数据

把目标行的 pick 改为 edit，保存并退出。pick 表示按原样重放，edit 表示重放到这一条后暂停，让你修改提交内容。这里不要随意改变其他行的顺序，否则任务就从“拆分一个提交”变成了“同时重排历史”。

暂停后取回内容，再按逻辑边界重新提交

rebase 在目标提交处暂停后，先把该提交的内容退回到工作区。这里的 HEAD^ 指目标提交的父提交；它不会删除文件改动，只是把改动从提交对象移回未暂存区域。

# 将当前暂停的提交退回工作区，保留全部文件改动
git reset HEAD^

# 查看哪些文件已修改，确认拆分范围仍然正确
git status

# 先只加入第一组逻辑改动，例如导出实现文件
git add path/to/export.go path/to/export_test.go

# 创建第一个职责单一的提交
git commit -m "增加导出字段"

# 再加入第二组改动，例如文档或示例
git add README.md docs/export.md

# 创建第二个职责单一的提交
git commit -m "补充导出字段说明"

如果同一个文件里混有两组改动，可以用交互式暂存：

# 按代码块选择要进入第一个提交的改动
git add -p path/to/export.go

# 先检查暂存区，再提交，避免把另一组改动一起带入
git diff --cached
git commit -m "增加导出字段"

# 剩余改动再次检查后提交
git diff
git add -p path/to/export.go
git commit -m "补充导出字段说明"

拆分的关键不是提交数量，而是每个提交都能独立解释：第一条解决什么问题，第二条为什么单独存在。每次 commit 前看一次 git diff --cached，能明显降低把两组改动交叉带入的概率。

继续 rebase，并知道什么时候停下来

两个新提交创建完后，让 Git 继续重放剩余提交：

# 让 Git 继续处理待办清单中的后续提交
git rebase --continue

# 查看最终历史，确认原来的一个提交已经变成多个职责清晰的提交
git log --oneline --decorate -n 6

顺利完成时，终端会出现成功提示，且日志中能看到刚创建的两个提交。如果后续提交产生冲突，按“解决冲突、加入已解决文件、继续”的顺序处理：

# 冲突解决并保存文件后，把解决结果放入暂存区
git add path/to/conflicted-file

# 继续重放当前提交
git rebase --continue

# 如果当前提交本来就不需要，明确跳过它
git rebase --skip

# 如果发现范围选错或不想改写历史，回到 rebase 前
git rebase --abort

--abort 是整次操作的回退开关；--skip 则会丢掉当前待办提交对应的重放，不应在“只是遇到冲突”时随意使用。

提交拆分后的三项确认

最后用下面三点核对结果：第一，git log 中出现了预期数量的新提交；第二，每个新提交的差异只服务一个逻辑目的；第三，如果分支此前已经推送，重新推送前先确认团队约定，通常需要显式的安全强制推送并通知协作者。

# 分别查看最近提交的摘要和补丁，确认拆分边界
git show --stat --oneline HEAD~1
git show --stat --oneline HEAD

# 确认工作区没有遗留的意外修改
git status

如果只是本地分支整理，到这里就完成了。若已经推送到共享分支，重点从“命令能不能执行”转向“新的提交哈希是否会影响别人”，必要时优先用新提交补救，而不是继续改写公共历史。

常见问题

为什么不能直接修改 rebase 待办里的 commit message 来拆分？

待办清单只控制提交的重放动作和顺序，改 message 不会自动把一个提交的文件改动分成两组。真正的拆分发生在 edit 暂停后的 reset、暂存和重新 commit 阶段。

拆分时误用了 git reset --hard 怎么办？

不要继续执行清理命令。先保留现场，并用 reflog 查找 reset 前的 HEAD；能否恢复取决于对象是否仍在引用和本地回收状态。更稳妥的拆分动作是使用不带 --hard 的 git reset HEAD^，让改动留在工作区。