Git 在 2.54 和 2.55 两个版本里，分两次加入了实验性命令 git history。2026 年 4 月发布的 2.54 带来 reword 和 split，2026 年 6 月发布的 2.55 补上 fixup。三个子命令合起来做一件事：更安全地改写旧提交，并自动同步所有从该提交派生出来的本地分支。
这不是什么颠覆性功能，但对每天和 rebase -i 打交道的人，是个实打实的补丁。它真正的看点不在命令本身——是 Git 开始把 jj（Jujutsu）身上被反复讨论的几个优点，直接吸收进核心工具链，不需要用户换一套系统。
三个子命令补的是哪笔老账
fixup 最实用。以前想把一处小修改折进几个提交之前的某次改动，标准流程要三步：git commit --fixup、rebase --autosquash，如果这个提交还被其他分支引用，还得再手动跑一次 rebase --update-refs。git history fixup <commit> 把这三步合成一步，还会自动追踪每一个从目标提交派生出来的本地分支，让它们的指针一起挪动。
reword 改旧提交的说明文字，split 把一个塞了多个改动的提交拆开，操作方式接近 git add -p。三者共享一条底线：只要可能产生冲突，命令直接拒绝执行，不会把树留在半改半冲突的状态里。
| 子命令 | 解决的问题 | 过去要手动做的事 |
|---|---|---|
| fixup | 把改动折进旧提交，同步本地分支 | commit --fixup + rebase --autosquash + rebase --update-refs |
| reword | 改旧提交说明 | rebase -i 手动改 message |
| split | 拆分旧提交 | 手写 rebase 脚本，配合 add -p |
它降低的是心智成本，不是要替代 jj
jj 把工作区本身当成一个提交，配了操作日志方便随时撤销，还能让冲突以一等公民身份留在历史里，之后再处理。这套模型确实优雅，代价是整个工作流都要换一遍：团队协作、CI 脚本、老手的命令习惯都要重来。
git history 走另一条路：不换系统，只在 Git 内部补几个高频痛点。它的原子性来自“拒绝风险”，不是“带着冲突往前走”——这是它和 jj 最本质的分歧，官方文档也明确写了这条限制。等 Git 真的学会处理一等公民的冲突，这道门槛才可能松动，眼下看不到时间表。
对日常写代码、经常做 fixup 和拆提交的个人开发者，这个功能现在就能在自己的分支上试试，能省掉不少手写 rebase 脚本的功夫。对正在评估要不要把团队迁到 jj 的技术负责人，这次更新还不构成改变计划的理由——它填的是 Git 内部的坑，不是 jj 想解决的那个更大的问题。
限制卡在哪：merge commit 和团队协作先别指望
git history 目前完全不处理含合并提交的历史。经常用 merge 而不是纯 rebase 工作流的团队，基本用不上。
它自动重写的也只是本地分支，不涉及远程分支或团队共享的历史。想靠它安全地重写协作历史，用错了地方。
命令还标着 experimental，不建议现在就写进团队规范或 CI 流程。真正该盯的变量，是 Git 什么时候给冲突处理一等公民待遇——那道门开了，git history 才可能覆盖合并场景，目前官方没给出时间表。
【锐评】先把 rebase 的坑填平，比急着追平 jj 更实际。