Git history：无需切换jj的修复利器
The Git history command deserves more attention
在并行处理大量变更时，Git 的分支和提交管理往往让人头疼，尤其是那些令人胆寒的 rebase -i 操作。虽然 jj 常被推崇为解决方案，但我尝试了多次最终还是回到了 Git。最近，Git 2.54 和 2.55 版本引入的实验性命令 git history 让我眼前一亮。它包含 fixup、reword 和 split 三个子命令，能自动修复旧提交、更新提交信息或拆分提交，并自动重基于所有相关分支。最重要的是，它保证了操作的原子性，绝不会让仓库处于半损坏状态。虽然它目前还无法像 jj 那样处理冲突，但作为 Git 核心的一部分，它无需额外安装就能提供许多 jj 的便利，是日常开发中一大进步。
git history 已经提供了人们推崇 jj 的诸多优势，却无需改变整个工作流程。
HN 评论区
21- 在商业环境中，Ticket 才是业务价值的单位，PR 应作为整体被审查并 Squash 合并，过度关注 Commit 层面的原子性对业务无实质意义。
- 对于存储、航空等对代码质量要求极高的领域，必须保持每个 Commit 独立可编译且通过测试，以便利用 git-bisect 进行回归定位，随意 Squash 会破坏这一能力。
- JJ 工具在本地操作体验极佳，但其与 Git 的互操作性高度依赖约定和纪律，若操作不当极易损坏远程仓库状态，修复难度极大。
- 当前 CI 流程普遍存在厂商锁定问题，导致测试无法在本地运行，开发者被迫依赖 GitHub Actions 等云端环境，这违背了工具应服务于本地开发的原则。
- 在 AI 辅助编程时代，由 AI 自动完成 Task-specific 的 Commit 是可行方案，强行要求人工维护原子化 Commit 反而增加了不必要的循环成本。