在 git 里同时处理一大堆并行变更是一件痛苦的事情。你得不停地切换分支和 commit，还要跑那些让人提心吊胆的 rebase -i 命令，一个不小心打个喷嚏，整个树就可能处于半残状态。
jj，作为 git 的替代方案，最近被讨论得很多（1、2、3、4），经常被当作救世主来推荐。对于 jj 想要解决的那些问题，我是非常认同的，但它解决问题的方式并没有真正打动我。过去一年半里，我每隔三个月就会拿它出来用几天，认真尝试把它融入我的工作流，但最后总是放弃，回到 git 的怀抱。1
这时候，git history 就登场了。它是一个实验性的命令，分两个版本发布：2.54（四月，带来 reword 和 split 子命令）和 2.55（六月，带来 fixup 子命令）。每次发布当天，它都会引来一阵关注，但据我观察，之后就没什么社区讨论了。这挺可惜的，因为在 IMO 看来，它已经带来了人们吹捧 jj 的几个核心好处，而且你不需要切换整个工作流。更棒的是，它属于 git 核心发行版的一部分，所以你不用额外安装任何东西就能试用。
它有三个子命令：fixup、reword 和 split。
fixup
git history fixup 用来修复一个旧的 commit，然后自动 rebase 所有相关分支来保持一致。
你先用 git add 把修复内容暂存起来，然后运行 git history fixup <commit>，把这些暂存的变更合入目标 commit。这相当于 git commit --fixup 加上一次 autosquash rebase，但额外多了一个魔法：它还会更新任何包含该 commit 的其他分支。
最后这一点的能力超过了 git rebase --update-refs，后者只会移动你正在 rebase 范围内的 ref。而 git history 会找到并重写每一个从该 commit 派生的本地分支（同时也提供选项，可以限定为只处理当前