Git 正在把改旧提交变成单独命令，但 history 还不能碰冲突
作者：林岚
林岚
OC 原创示意图。
据开发者 Lalit Maganti 的实测介绍 和 Git 官方文档，Git 正在试验一个新的 git history 命令，用来直接改写历史提交。Git 2.54 加入 reword 与 split，Git 2.55 又加入 fixup，目标是把过去依赖交互式 rebase 的常见操作变成更明确的单条命令。
一句话结论： git history 终于让“修改旧提交”更接近普通编辑操作，但它仍是实验功能，遇到合并提交或冲突会直接拒绝执行，现在还不能替代完整的 rebase 工作流。
以往想修改三次提交之前的一条说明，通常要运行 git rebase -i、找到目标提交、把 pick 改成 reword，再一路完成重放。想把当前修改补进旧提交，则要先做 fixup commit，再执行 autosquash。熟练用户已经习惯这套仪式，但它把“我要改哪一条”变成了“我要如何编排一段重放脚本”。
新命令把意图直接写出来。git history reword <commit> 修改旧提交消息，git history split <commit> 交互式拆分提交，git history fixup <commit> 把暂存区变化并入指定提交。更实用的一点是，它会尝试更新所有本地后代分支，而不是只移动当前分支，因此在一组层叠分支中改动底部提交时，不必手工逐个 rebase。
OC 原创解释图：三个子命令对应三种最常见的历史编辑意图。
Git 为了避免“方便”变成意外破坏，目前采取了很保守的策略：只要更新任何后代分支可能产生冲突，整个操作就不会执行；包含 merge commit 的历史也暂不支持。这让它的行为更容易理解，却意味着复杂仓库仍要回到 rebase --onto、--rebase-merges 或专门工具。
它和 Jujutsu 这类新一代版本控制工具也还有明显距离。Jujutsu 把工作副本视为提交，冲突可以作为一等状态保存，还有操作日志与简单撤销。git history 只是在 Git 现有对象和分支模型上补一组更友好的改写命令，没有改变 Git 对冲突、工作区和历史的基本理解。
另一个必须提醒的事实是，历史改写仍然是历史改写。提交哈希会变化，已经推送并被别人基于其开发的分支可能需要重新同步。新命令降低的是本地操作复杂度，不会消除协作成本。团队仍应保护主分支，并在强制推送前确认影响范围。
本站编辑林岚认为，git history 是一个看似小、实际很符合开发者需求的改进。Git 不缺能力，缺的是让用户直接表达意图的界面。与其要求每个人背熟交互式 rebase 的状态机，不如让常见任务拥有名字。不过官方已经把它标成 EXPERIMENTAL，脚本和团队规范现在都不该依赖其行为永远不变。
想试用的人可以先在个人分支或测试仓库里使用，确认本地 Git 至少为 2.55，并在操作前查看将被移动的分支。它最适合干净、线性的本地历史；一旦涉及合并、冲突和已经共享的提交，老工具暂时仍更可靠。
评论
围绕这篇文章补充信息、提出问题或分享观察。