用Jujutsu战胜Git严谨疲劳

# 用 Jujutsu 战胜 Git 严谨性疲劳 来源：https://ikesau.co/blog/defeating-git-rigour-fatigue-with-jujutsu/ 本文假定你对 `jujutsu` 版本控制系统（https://docs.jj-vcs.dev/latest/）有基本了解。如果你没用过 jujutsu，你仍然能理解核心思路，但我建议后续阅读 [Steve 的 Jujutsu 教程](https://steveklabnik.github.io/jujutsu-tutorial/)。 在开发大型功能时，写出“好的提交”很难。 所谓“好的提交”，我指的是像这样： `定义类型` `添加数据库函数` `服务端 CRUD` `客户端 API` `客户端 UI` 这样可以使审阅者逐步浏览你的拉取请求，每次只看功能的一个小方面。 那么，很自然的，我实际做的是这样： `定义类型` `添加数据库函数` `WIP 测试代码` `服务端 CRUD` `客户端 API 和 UI` `修复数据库函数` `修复 UI 错误` `重构 CRUD` `修复另一个 UI 错误` 后面的提交覆盖了前面提交的工作，故事线就断了。⚖️ Jujutsu 让在不同提交间跳转、快速迭代分块变更集变得更容易，但依然需要投入精力，我往往有抵触心理。🤖 `jj absorb`（https://docs.jj-vcs.dev/latest/cli-reference/#jj-absorb）有一定帮助，`jj squash -i`（https://docs.jj-vcs.dev/latest/cli-reference/#jj-squash）也是，但两者都有缺点： 1. `absorb` 会根据哪个之前的提交最近修改了这些文件来分配变更，但有时这并不对应这些变更本该属于哪个提交。 2. `squash` 如果你的边界不够干净，可能会让你陷入合并冲突的泥潭。 所以我针对这种“Git 严谨性疲劳”问题想出了一个解决方案。 在这个例子中，我们用直观的方式表示提交。想象红色代表对类型定义的更改，蓝色代表 UI，以此类推： 混乱不堪。我们的第一个提交是红色和蓝色的混合。我们在多个地方触碰了红色！ 为了修正，我们先创建理想的提交历史，使用 `jj new -B messy-first -m 'red'` 然后我们继续创建剩下的。（此时我切换到 `jj new -A red -m 'blue'`） 接下来我们把所有有实际更改的提交 squash 成一个，使用 `jj squash --from messy-first..messy-last --into messy-first` 然后我们使用 `jj squash -i --from messy-first --into red` 并挑选出红色的更改，把它们放到红色盒子里： 依此类推： 最终所有更改都放到了正确的位置，“everything 提交”变空了。 对于大型功能，我发现这种工作流比在功能开发全过程中维持严格的 Git 严谨性要轻松得多。把临时的调试状态放进随意即兴的提交中，最后一次性整理干净，这样更容易。 ### 注意事项： 1. 我给这个技巧取不出好名字。“像一大筐脏衣服那样做提交”，也许？ 2. 这与 `jj split` 不同（我认为更优）：1. 使用 `split`，如果我漏掉了一个本应属于红色的 hunk，就必须再次 split 然后 squash。2. 这个技巧更容易在开始时排序最简单的 hunk，而不用担心它会影响提交的顺序。 3. 之所以（通常）在最后一次性完成比在过程中使用 `jj squash -i` 更好，是因为“everything 提交”的最终状态保证不会有任何冲突。创建一个新的“修复红色和绿色”提交然后交互式 squash 进你的红色和绿色提交，可能会破坏你的蓝色提交——如果它刚好触及了受影响的文件。 4. 这个技巧的一个缺点是：无法保证每个提交都能编译通过，这可能是致命缺陷。