改提交历史不用再敲 `git rebase -i` 了

如果你改过 Git 提交记录，大概率用过 git rebase -i，这个命令功能全面，但上手门槛较高，让不少开发者望而生畏：改提交备注、补充遗漏代码、拆分臃肿提交，每一步都要进入交互界面、手动调整操作清单，流程繁琐。

Git 并没有打算淘汰 rebase，但在最近的两个版本中，推出了一套全新的历史编辑工具。

Git 在 2.54 版本中首次上线实验性 git history 主命令，同时提供 reword、split 两个子命令；到 Git 2.55 版本，又新增了 fixup 子命令。

日常开发中，调整提交历史基本离不开这三类场景：

• 提交备注写错，需要修改；
• 提交完成后，发现还有代码漏写，需要补进某次提交；
• 单次提交代码量过大，拆分成多个小的提交，方便代码评审。

目前这三类场景都可以通过 git history 一个命令进行操作。

和 rebase -i 的区别

初次接触 git history，会误以为它只是把 rebase -i 做了一层封装、简化输入指令。但 Git 官方强调，二者核心差异体现在运行机制上：

1. 操作原子性

使用 git history 修改历史时，如果中途产生代码冲突，命令会直接终止，不会留下未完成的操作状态，不用开发者手动清理残留变基流程。

2. 不污染本地工作区与暂存区

reword、split 等操作不会改动当前未提交代码和暂存文件，只想修改历史记录、不打断手头开发的场景下，体验远优于传统变基。

3. 自动同步所有关联分支

修改提交后，命令会自动更新所有引用该提交的下游分支，而不像传统变基仅更新当前分支，这也是官方重点优化的特性。

由此可见，git history 绝非简单的命令包装，而是 Git 对提交历史编辑交互逻辑的一次重新设计。

场景 1：修改历史提交备注

假设当前提交链路如下：

A ── B ── C ── D (HEAD)

若提交 C 的备注存在错误，传统写法需要：

git rebase -i HEAD~3

在编辑界面里，将

pick C

手动修改为

reword C

使用新命令只需一行：

git history reword C

执行完成后 Git 会生成全新提交对象，提交链路更新为：

A ── B ── C' ── D'

全程无需编辑变基操作清单，步骤大幅简化。

场景 2：给已有提交补充遗漏代码

开发中经常出现提交完毕，才想起还有代码漏提交的情况。传统操作需要多步组合：

git add <files>
git commit --fixup <commit>
git rebase --autosquash <commit>~

改用 git history 精简为两步：

git add <files>
git history fixup <commit>

注意：fixup 会读取暂存区的代码变更，执行前必须先用 git add 把修改加入暂存。

场景 3：拆分体积过大的提交

代码评审阶段，评审人有时会建议：单次提交内容过多，建议拆分为多次提交。传统方式需要手动中断变基、拆分代码、重新整理提交，操作繁琐。现在直接执行：

git history split <commit>

Git 会交互式引导开发者按代码块（hunk）自主选择内容，将单个提交拆分为两个新提交，不用全部回退后再重新分批提交。

目前还无法完全替代 rebase

尽管 git history 降低了改历史的上手难度，但目前还有不少短板，无法覆盖全部场景：

• 整体仍处于实验阶段（EXPERIMENTAL），功能稳定性有待打磨；
• 不支持包含合并提交（merge commit）的历史记录；
• 操作触发冲突时会直接中止，不会进入交互式冲突解决界面；
• 复杂的多分支历史操作，依旧需要依靠 git rebase -i。

二者适用场景区分：git history 负责日常高频、简单的提交修改；rebase -i 处理复杂、深度的历史重构工作。

Git 为什么要上线 git history

结合版本更新日志与 GitHub 技术博客能看出，这个新的命令主要是改善提交历史编辑的使用体验。

之前 Git 所有历史高级编辑功能都集中在 rebase -i 命令上面，功能堆砌导致学习成本高。Git 这次把常用操作拆分为独立的子命令，省去了用户反复进入变基交互界面的步骤。

另外，最近几年 Jujutsu（jj）等新一代版本控制工具，凭借简洁易用的历史编辑功能收获大量开发者好评。虽然 Git 未明确表示 git history 借鉴了同类工具，但从设计思路来看，降低认知成本、简化操作流程，已经成为 Git 连续多个版本的核心优化方向。

目前 git history 还在持续迭代优化，从 Git 2.54、2.55 两个版本的更新能看出，官方已经把优化历史编辑体验列为重点工作。