審查並合併 PR

本指南說明如何審查並合併一個 pull request。

開啟 PR 工作台

1. 在側邊欄中前往 Pull requests
2. 從清單中選擇一個 PR

PR 會以分頁式工作台的形式開啟，而不是單一頁面。預設會依下列順序開啟五個分頁： 總覽、Diff、原始碼控制、聊天 和 操作（按工作流程分組的 CI 檢查）。 檢閱 —— 先顯示審查管線的進度，接著顯示它發佈的產出物及其發現項側欄 —— 刻意不在 其中：在有人主動要求之前，PR 並沒有審查，因此由 詢問 AI 開啟它。終端、單一檔案 編輯器、內嵌的 code-server 和應用程式內瀏覽器都按需開啟；當在 PR 上偵測到預覽 URL 時， 會自動注入部署預覽分頁。你的分頁版面會按 PR 分別記住。

總覽分頁承載 PR 的中繼資料（作者、分支、標籤、指派對象、表情反應、提交、檢查狀態） 以及操作列：重新整理、檢閱、合併、在 IDE 中開啟，以及一個 ⋯ 溢位選單。

閱讀 diff

開啟 Diff 分頁，即可一次過查看整個 PR 的 diff，並有一個用於在檔案之間跳轉的檔案樹。

• diff 工具列中的設定按鈕可在 分欄（並排）與 統一 檢視之間切換，並開關自動 換行與程式碼字型連字。
• @@ 差異區塊標頭會被 Show N lines / Show end of file 控件取代，點擊後會把 周圍的上下文拼接進來。
• 按 j / k 在檔案之間逐一移動，按 c 摺疊或展開聚焦的檔案，按 t 讓側邊欄回到 檔案樹，按 ⌘F 在整個 diff 中搜尋（Enter / Shift+Enter 在匹配項之間移動）。
• 按 v 把聚焦的檔案標記為已檢視，游標隨即前進到下一個檔案。在 GitHub 上，已檢視 狀態儲存在託管平台上，因此會跟隨你在各個用戶端之間；GitLab 和 Bitbucket 沒有這類 API，所以在該處它只記住在本機。

在程式碼區域拖曳滑鼠可選取精確到某一欄的文字，⌘C 複製的是原始原始碼，而不是渲染後 的 diff 標記。

留下行內評論

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 輔助審查
• 派發審查代理
• 審查運算（群體與軸向）
• 連接程式碼託管