用惯了十年的修复式提交？Git 2.55 新命令一步到位

　　你一定经历过这个固定动作：分支已经整理得差不多，突然发现某个改动其实应该塞进三个提交之前的那次提交里。于是你熟练地敲下 git commit --fixup，再跑一遍 git rebase --autosquash。这套操作你已经跳了快十年，像肌肉记忆一样无需思考。

　　Git 2.55 悄悄上线了一个实验性子命令，把这两步直接压缩成一步，让你从此告别那个重复了十年的固定动作。这个命令就是 git history fixup，它会把你暂存区里的改动直接“缝”进指定的历史提交，然后自动重放之后的所有提交，一气呵成。

　　如果有环境还没升级

　　Ubuntu 24.04 的默认源里 Git 还是 2.43，而 git-core PPA 在我写这些的时候也只到 2.54。git history 在 2.54 就已经出现，但 fixup 子命令是 2.55 才加入的。如果你的发行版还没有跟上，最简单的办法就是从源码构建。注意 2.55 默认会包含 Rust 组件，如果机器上没有 cargo，可以加上 make NO_RUST=1 来跳过。

　　实际用法：三步变一步

　　用一个真实仓库来演示。仓库里只有三个提交，根提交是一份松饼食谱，可惜它把最灵魂的枫糖浆漏掉了：

　　$ git log --oneline1c27b69 (HEAD -> main) add serving size607de8b add method85873a0 add pancake recipe

　　先把漏掉的枫糖浆加入食材清单并暂存：

　　$ printf -- '- maple syrup\n' >> pancakes.md$ git add pancakes.md

　　放在以前，这里就要创建修补提交再变基，中间还可能被 todo 列表打断。现在一条新命令直接完成：

　　$ git history fixup 85873a0

　　Git 二话不说就把这个改动塞进了食谱提交里。日志刷新后，所有后续提交的哈希值虽然都变了（历史重写的基本原理），但内容关系完全维持原样：

　　$ git log --oneline3a459f9 (HEAD -> main) add serving size0e42f1e add method3f4de5e add pancake recipe$ git show 3f4de5e:pancakes.md# pancakes- 100g flour- 2 eggs- 300ml milk- maple syrup

　　枫糖浆就像一开始就写在那里一样自然地出现了。提交信息没变，作者身份没丢。如果你想趁机修改信息，加个 --reedit-message 参数就行。整个过程不弹编辑器，不看 todo 列表，也不需要传 --autosquash 参数。

　　冲突处理：要么全干完，要么一点都不动

　　这个命令最让人喜欢的设计，恰恰是它处理冲突的方式。

　　用 git rebase --autosquash 遇到冲突时，你会被扔进一个半截的变基里，带着冲突标记和分离头指针，原本打算快速修补的小操作，转眼就变成十分钟的大扫除。而 git history fixup 的做法完全相反：它要么把整个操作执行干净，要么一丝不动地退出，绝不留半成品。

　　我故意制造了一个冲突——改了一行，而后续某个提交也碰了同一行：

　　$ git history fixup HEAD~1error: fixup would produce conflicts; aborting

　　退出码 255，分支纹丝未动，暂存区的改动还留在暂存区，一切像没发生过一样。这种“整事务”式的行为，对日常修修补补的绝大多数场景太友好了：拼写错误、漏掉的文件、忘了添加的注释，这些本来就应该干净利落地折进原来的提交，不惊动任何不必要的历史回溯。

　　安全气囊与后悔药

　　该有的保护一样没少。--dry-run 会先告诉你这次操作会把引用更新到哪里，而不真正执行：

　　$ git history fixup 85873a0 --dry-runupdate refs/heads/main 3a459f9668... 1c27b69d

　　如果真的执行了又反悔，也不用慌——Git 的引用日志里永远留着操作前的指针。你可以用 git reflog 或 git undo（如果你配置了别名）轻松回到上一个安全点。加上分支本身就是你本地的实验场，大胆用就是了。