git history 命令：Git 原生的安全改历史利器，值得更多关注
文章摘要
Lalit Maganti 在这篇文章里力荐 Git 2.54 和 2.55 版本中新引入的实验性命令 git history，认为它是处理复杂并行开发工作流时，无需切换到 jj（Jujutsu）的一个务实替代方案。
文章先点出痛点：在 Git 里管理多条并行分支和一连串提交非常繁琐，开发者常常被交互式 rebase 折磨——它可能把仓库状态搞乱，需要在各分支间反复跳转、执行高风险操作。而 git history 通过三个子命令，把这些操作变得原子化、非破坏性且不需要来回 checkout：
fixup：把一处修正暂存到某个较早的提交上，然后自动 rebase 所有派生出来的分支。与标准的 git rebase --update-refs 不同，它会”找出并重写从该提交派生出来的每一条本地分支”，且不支持合并提交（merge commit）。整个操作是原子的，不会留下半成品状态。
reword：修改历史提交的信息，并重建其上方的提交栈。因为它只操作提交图、不碰你的索引和工作区，所以不会打扰当前的工作状态。
split：通过交互式选取 hunk，把一个提交拆成两个——用户逐块审查某个提交内的改动，把相关修改分离到不同提交里。
三个命令的共同优点是原子性（要么完整完成、要么整体失败）和无损的历史操作，无需 checkout 来回折腾。局限在于它们无法处理合并提交，也不能像 jj 那样携带冲突状态继续工作，这在某些场景下会限制其适用性。
HN 评论精华
- WorldMaker：认为
git history是初级开发者学习 Git 的安全踏板——它在保留能力的同时避免了git rebase的种种”走火”陷阱，具有很高的教学价值；他后续还讨论了让history保持高层、rebase保持底层之间的设计张力。 - nine_k：提出相反视角——对已经用惯交互式 rebase 的老手来说，
git history的价值有限，资深用户可能会直接略过它。 - bulatb：一针见血地指出，即便你完全理解 Git 各操作的原理，也不代表它的用户体验就令人愉快；理解并不能消除复杂工作流带来的糟糕手感。
- seba_dos1：为 Git 辩护，认为它的 UX 一直在改进，
--update-refs等近期新增功能就说明社区对可用性问题是有回应的。 - shepmaster：从技术层面剖析
git history如何自动更新多条依赖分支，并与只影响当前范围的git rebase --update-refs做了对比，点出了新命令的实质增益。 - rmunn：分享了一个”被低估”的技巧——在 rebase 前后对提交做 diff，以验证冲突解决是否正确，能有效抓出改历史时引入的错误。
- BeetleB：把 jujutsu 更简单的
undo拿来做对照，提醒 Git 在撤销工作流上仍有可借鉴之处。