GitHub Copilot Code Review 核准怎麼開？安全設定與檔案範圍

先分清楚 assessment、approval 與 merge requirement#

可以把一次 Copilot code review 拆成三層：

GitHub 的新流程會在每次 review overview comment 顯示 approval assessment，但 assessment 單獨不會變成 required approval。管理員應把「讓 Copilot 產生評估」和「讓 Copilot 影響 merge gate」當成不同風險決策。

Repository 層的兩組設定#

Repository 需要分別處理「何時自動 review」和「approval 是否有合併權限」。

File paths 是 approval 範圍，不是 review 範圍#

Auto-approval 的 File paths 可以限制哪些 pull request 的 Copilot approval 能計入 merge requirements。規則有三個重點：

• 每行一個 file glob。
• 最多支援 15 個 glob。
• pull request 的所有 changed files 都必須符合其中一個 glob，approval 才能依這個範圍計入。

例如只想讓文件變更使用 Copilot approval，可以先從這種範圍開始：

1
docs/**
2
**/*.md

這不是說 docs/guide.md 會被 review、而 src/app.ts 不會被 review；它控制的是 approval 是否能被當成 merge gate 的一部分。如果一個 pull request 同時修改 docs/guide.md 和 src/app.ts，因為不是所有 changed files 都符合上面的 glob，這次 approval 就不應依該範圍計入。

若 repository 的路徑規則很複雜，先用一個預期會通過的純文件 PR 和一個混合路徑 PR 做對照。不要把 glob 內容只放在管理員筆記；它本身就是 approval policy 的一部分，應和 branch ruleset 名稱、owner 和審核日期一起留存。

Organization 與 Enterprise 要先決定治理邊界#

Organization 可以替多個 repository 設定自動 code review，也可以透過 repository scope 選擇哪些 repository 套用。Enterprise 則可以把管理範圍再往上收斂；實際 UI 會依你使用的方案和權限顯示可用選項。

建議採用以下順序：

1. Enterprise／organization 先決定是否允許 Copilot approval 進入治理政策。
2. Repository 再決定是否啟用 auto-approval，以及是否限制 File paths。
3. Branch ruleset 明確指定哪些分支需要 review、CI 與人類審查。
4. 由 repository owner 建立測試 PR，確認 assessment、approval 和 merge requirement 的結果。

Copilot code review 的 effort level 也在同一個 repository 設定頁面，但它是 review 深度選擇，不是 approval 權限。若想先調整檢查深度，可參考 Copilot code review 的 Lite 與 Balanced；不要把 effort level 的變更當成已開啟 auto-approval。

新 commit 會讓 approval 失效#

GitHub Changelog 特別說明，pull request 有新 commit 時，Copilot approval 會像人類 review 一樣被 dismiss。這是合理的安全邊界：approval 只對被 review 的 commit snapshot 有效。

因此 rollout 時應測試：

1. 建立一個符合 File paths 的純文件 PR。
2. 等待 Copilot 完成 review，確認 overview 有 approval assessment。
3. 在 repository policy 允許時，確認是否出現 Copilot approving review。
4. 檢查 branch ruleset 是否把它計入 required approvals。
5. 再 push 一個小修改，確認舊 approval 被 dismiss，並要求新的 Copilot review。
6. 在新 review 完成前，確認 PR 不會因舊 approval 仍留在畫面上就錯誤合併。

如果團隊把 required approvals 當作唯一 gate，還要同時確認 CI、CODEOWNERS、人類 review 和其他規則沒有被這項 preview 功能意外繞過。Copilot approval 只能是既有治理設計中的一個明確節點。

建議的漸進式開放順序#

對多數團隊來說，下面的 rollout 風險較容易控制：

• 第一階段只開自動 review，觀察一到兩個迭代的 false positive、漏報和回應時間。
• 第二階段只在文件、測試或已定義的低風險目錄設定 File paths，保留人類 review。
• 第三階段才評估是否讓 Copilot approvals count toward merge requirements。
• 每次變更都用一個新增 commit 的 PR 測試 dismiss／re-review 行為。
• 對高風險、權限、付款和資料庫 migration 目錄，保留更嚴格的人類或 CODEOWNERS 審查。

這些是治理建議，不是 GitHub 的強制規則。真正要記錄的是團隊願意讓 Copilot 在哪一種變更上影響 merge decision，以及誰負責回溯 preview 行為。

結論：先把 approval 當成可控的額外 reviewer#

Copilot code review 的 approval 功能可以減少低風險 pull request 的等待時間，但它不應被簡化成「AI 說沒問題就能 merge」。先分清 assessment、approving review 和 merge requirement，再於正確層級開啟 toggle，並用 File paths 限制可計入的變更範圍。最後一定要測新 commit dismiss 舊 approval 的流程，讓 branch protection 看到的是最新 snapshot 的結果。

常見問題#