代码审查是软件工程中最重要的质量保障手段之一，但当面对一个包含数百个文件、数万行代码变更的大型PR时，即便是最有经验的审查者也容易迷失。传统的Git工作流在处理这类场景时往往力不从心——你需要记住哪些文件看过了、哪些还没看、哪些意见已经解决了。这份"心理清单"本身就是一种认知负担。Ben Gesoff最近分享了一套基于Jujutsu的工作流，尝试用工具来解决这个问题。

Jujutsu是一个新兴的版本控制系统，被设计为Git的替代者。它的核心设计理念是利用不可变的事务和自动追踪的变更图来消除传统Git操作中的很多陷阱。在代码审查这个具体场景上，Jujutsu的几个特性发挥了关键作用。

首先是jj duplicate命令。这个命令可以复制一个变更，并保留与原始变更的关联。当审查者需要review一个大型PR时，第一步就是把这个PR对应的变更复制一份。复制品与原始变更相互独立，审查者可以自由操作而不影响原始代码。

第二步是创建一个空的父提交。通过这个jj new --no-edit --insert-before @命令，审查者可以在当前变更的下方插入一个空提交。这个空提交将成为一个"已审查"的锚点——每当你审查完一部分文件，就把那些文件的变更压缩进这个空提交里。

这个压缩操作通过jj squash命令实现。当你把一组文件的变更squash进父提交后，这些文件就正式标记为"已审查完成"，而不会再出现在待审查的变更列表里。剩下的未审查文件保持原样，审查进度完全可视化——你能看到哪些文件已经被squash进去了，哪些还在那里等待审查。

这个工作流的精妙之处在于它的"持久化"特性。传统的Git工作流中，如果你暂停了审查第二天继续，你可能需要花时间回想"昨天看到哪儿了"。而在Jujutsu的工作流里，审查状态完全保存在版本历史中——那些已经被squash进父提交的文件，就是你昨天完成的部分，不需要任何额外的笔记或文档来记录。

与这个方案形成对比的是业界其他大型代码审查系统的思路。TigerBeetle采用了一种称为"分层审查"的方法，将大型变更拆解成多个逻辑层次逐层审查；Jane Street则开发了Iron系统，专门用于追踪代码审查中的对话线程和决策历史。Jujutsu的这套工作流与这些系统的思路不同——它不需要任何特殊的基础设施，只需要一个Git替代品，任何团队都可以直接采用。

当然，这套工作流的前提是团队愿意从Git切换到Jujutsu。这个迁移成本对于大多数团队来说并不低。但Gesoff指出，Jujutsu与Git的兼容性非常好——你可以把Jujutsu仓库当作一个普通的Git仓库来使用，两者的边界是透明的。如果你正在处理一个超大型项目、频繁遇到"PR太大看不过来"的问题，这套工作流值得评估。

参考来源：https://ben.gesoff.uk/posts/reviewing-large-changes-with-jj/