审查并合并 PR

本指南介绍如何审查并合并一个 pull request。

打开 PR 工作台

1. 在侧边栏中导航到 Pull requests
2. 从列表中选择一个 PR

PR 会以标签式工作台的形式打开，而不是单个页面。默认会按以下顺序打开五个标签页：概览、 Diff、源代码管理、聊天 和 操作（按工作流分组的 CI 检查）。评审—— 先显示审查流水线的进度，随后显示它发布的工件及其旁边的发现项侧栏——被刻意排除在这些 标签页之外：在有人请求审查之前，PR 没有审查，因此由 询问 AI 打开它。终端、单文件 编辑器、内嵌的 code-server 和应用内浏览器都按需打开；当在 PR 上检测到预览 URL 时，会 自动注入部署预览标签页。你的标签页布局会按 PR 分别记住。

概览标签页承载 PR 的元数据（作者、分支、标签、指派对象、表情回应、提交、检查状态） 以及操作行：刷新、评审、合并、在 IDE 中打开，以及一个 ⋯ 溢出菜单。

阅读差异

打开 Diff 标签页，可一次性查看整个 PR 的差异，并带有一个用于在文件之间跳转的文件树。

• 差异工具栏中的设置按钮可在 分栏（并排）视图和 统一 视图之间切换，并开关自动 换行与代码字体连字。
• @@ 差异块头部会被替换为 Show N lines / Show end of file 控件，点击后会把 周围的上下文拼接进来。
• 按 j / k 在文件之间逐一移动，按 c 折叠或展开聚焦的文件，按 t 让侧边栏回到文件 树，按 ⌘F 在整个差异中搜索（Enter / Shift+Enter 在匹配项之间移动）。
• 按 v 把聚焦的文件标记为已查看，光标随即前进到下一个文件。在 GitHub 上，已查看状态 存储在代码托管平台，因此会跟随你到各个客户端；GitLab 和 Bitbucket 没有这样的 API， 所以在那里该状态只记忆在本设备上。

在代码区域用鼠标拖动可以选择精确到某一列的文本，⌘C 复制的是原始源代码，而不是渲染后 的差异标记。

留下行内评论

1. 点击代码行的行号栏，可打开锚定到该行的评论撰写框；若要添加文件级评论，请使用文件 头部的 + 按钮
2. 用 Markdown 写下你的反馈
3. 提交

在 GitHub 和 GitLab 上，撰写框提供两种提交方式：添加单条评论 会立即发布，而 开始审查 / 添加到审查 会把评论加入一个待处理的审查，该审查会随 批准、 请求变更 或 评论 一起发出。Bitbucket 没有待处理审查的批处理机制，因此在那里 每次提交都会立即发布。立即发布的评论在代码托管平台确认之前会显示为待处理状态，随后 转为已同步。如果发布失败，该讨论串会被标记为出错，并提供重试。

只有审查的_正文_是草稿：它会在你停止输入片刻后，以 (owner, repo, PR number) 为键保存 在服务器端，因此能经受重新加载，并跟随你在桌面客户端和 Web 客户端之间切换。

提交审查

1. 在概览的操作行中按下 评审（在你自己的 PR 上，以及在已关闭或已合并的 PR 上，它 会被隐藏）
2. 编写审查正文。你可以附加图片、插入表情符号或 GIF，并在编写和预览之间切换
3. 按下 请求变更、评论 或 批准

判定_就是_这个按钮——没有单独的判定选择器。按下 批准 或 请求变更 后，按钮会 改名为 已批准 或 已请求变更，草稿正文也会被清空。评论 判定则让按钮保持 评审 标签。

提交不可撤销

pr_review.submitReview 会发布到代码托管平台，且永远不会进入撤销栈。Control Center 中 没有“取消提交”这一操作。

合并

当你拥有写入权限，且该 PR 处于打开状态、不是草稿时，合并 按钮就会出现。它的颜色是 根据必需批准和检查状态（ready / pending / blocked）推导出的就绪信号——仅供参考。该 按钮绝不会因审查状态而被禁用；真正执行规则的是代码托管平台自身的分支保护。

1. 按下 合并 打开合并浮出面板
2. 选择一种合并方式：squash、merge commit 或 rebase（默认为 squash）。 Bitbucket 没有真正的 rebase 合并，因此 rebase 会映射到它的 fast-forward 策略，并在 分支已分叉时失败
3. 对于 squash 和 merge commit，可以编辑已预填的提交标题和描述。rebase 两者都不接受， 并会隐藏这两个字段
4. 阅读警告面板——它会列出失败的检查和待处理的审查，但不会阻止你继续
5. 在浮出面板中按下合并按钮以确认

合并不可撤销：它会把提交推送到代码托管平台，因此它得到的是一个确认步骤，而不是撤销 记录。之后，该 PR 的缓存会失效，其状态变为 已合并，并触发一个状态为 merged 的 PullRequestStatusChanged 事件。该事件会释放临时的“在编辑器中打开”工作树，并启动两条 预置流水线：Stale repository cleanup（删除该 PR 过时的工作树和对话文件夹）和 Release notes（起草一条变更日志条目）。

PR 审查空间不会自动归档

审查空间对话的自动归档接到的是一个独立的 PrMerged 领域事件，目前产品中没有任何地方会 发出它，因此合并后该空间会保持你离开时的样子。每日清理扫描仍会回收它的工作树；如果你 希望它从侧边栏中消失，请自行删除该空间。

把 PR 交给审查智能体

概览标签页上的 ⋯ 溢出菜单包含 询问 AI，它会为该 PR 启动预置的 pr_review 流水线。它只在 PR 处于打开状态时出现。流水线会做什么、以及如何发布它的发现项，见 使用 AI 审查；确定性的队列与轴模型见 审查计算。

审查外部 PR

Control Center 也会导入由应用外部的人打开的 PR。上面的审查流程完全相同。外部 PR 由 PR 轮询服务检测。

相关指南

• 使用 AI 审查
• 派发审查智能体
• 审查计算（队列与轴）
• 连接代码托管