用柔术战胜 Git 严格疲劳

使用 jujutsu 计算机克服 git 严格疲劳这篇文章假设您对 jujutsu 版本控制系统有基本的熟悉程度。如果您没有使用过柔术，您仍然会明白这个想法的要点，但我建议您先阅读 Steve 的柔术教程。当开发一个大型功能时，编写良好的提交是很困难的。良好的提交，我的意思是这样的： 定义类型 添加数据库功能 服务器 CRUD 客户端 API 客户端 UI 这允许审阅者逐步完成您的拉取请求，每组更改范围仅限于该功能的单个方面。因此，很自然地，我会这样做：定义类型添加数据库功能WIP测试代码服务器CRUD客户端API和UI修复数据库功能修复UI错误重构CRUD修复另一个UI错误稍后提交覆盖在早期提交中完成的工作并且故事中断。 ⚖️ Jujutsu 可以更轻松地跳转提交并快速迭代划分的变更集，但它仍然很费力，我对此感到厌恶。 ? jj extract 有所帮助，就像 jj squash -i 一样，但它们都有各自的缺点：absorb 根据最近接触这些文件的先前提交分配更改，这有时实际上并不对应于哪个提交应该拥有这些特定更改。如果你的边界不是非常干净，squash 会让你陷入合并冲突地狱。所以这是我想出的解决“git 严格疲劳”问题的方法。对于此示例，让我们直观地表示提交。想象一下，红色代表类型定义的更改，蓝色代表 UI 的更改，依此类推：混乱。我们的第一个提交是红色和蓝色的混合。我们在多个地方触摸红色！为了解决这个问题，我们首先使用 jj new -Bmessy-first -m 'red' 创建理想的提交历史记录，然后我们就可以完成剩下的事情了。 （此时我切换到 jj new -A red -m 'blue'）然后我们将所有包含实际更改的提交压缩为 jj squash --frommessy-first..messy-last --intomessy-first 然后我们使用 jj squash -i --from --into red 并挑选出红色更改，将它们放入红色框中：依此类推：最终一切都在正确的位置，并且“所有提交”都是空的。对于大型功能，我发现这个工作流程比在功能开发的生命周期中保持严格的 git 严格性要容易得多。使用其中的临时调试状态进行即兴提交并在最后一次性清理干净会更容易。先发制人：我对这种技术没有一个好名字。也许“像一大堆衣服一样进行承诺”？这与（并且，在我看来，优于） jj split 不同：使用 split ，如果我错过了应该是红色的大块，我必须再次拆分并挤压。这种技术更容易地允许在开始时对最简单的块进行排序，而不必担心它将如何影响提交排序。为什么最后完成这一切（通常）比使用 jj squash -i 更好，是因为保证所有提交的最终状态不会有任何冲突。创建一个新的“修复红色和绿色”提交并以交互方式将其压缩到红色和绿色提交中，如果它碰巧触及受影响的文件之一，则可能会破坏您的蓝色提交。这种技术的缺点是不能保证每次提交都会编译，这可能会破坏交易。