代码审查工作区应帮助你将拟议的意图、修改的行、运行时证据以及最终决定联系起来。它不应要求你保持组织内的每个代码仓库和仪表板都处于打开状态。

建立审查边界

阅读拉取请求的描述、关联的问题、基础分支以及受影响的行为。GitHub 建议在审查“Files changed”（已更改文件）之前先构建上下文。记下风险最高的文件和预期的验证，然后在编辑器中打开对应的代码仓库和分支。

当需要在定义之间进行导航时，将差异与本地代码并排放置。将测试或构建输出保留在终端窗口中，并且仅在更改具有用户可见的行为时才打开产品预览。只有在检查了当前版本后才标记已审查的文件；当文件更改时，GitHub 会清除已查看状态。

将证据与讨论分开

针对具体发现使用行内评论，针对确切编辑使用建议，针对综合结论使用审查摘要。检查拉取请求的自动检查（Checks），并在相关时检查依赖项更改。绿色的检查标记不能替代对源码差异的阅读。

以审查决定收尾

根据代码仓库的审查策略和观察到的证据，提交评论（Comment）、批准（Approve）或请求更改（Request changes）。之后停止本地进程并关闭临时窗口。Wallo 可以将差异浏览器、编辑器、终端和预览窗口组合在一起，但它并不知道拉取请求的状态或审查决定。