題干與適用場景
多個團隊共同維護儲存庫，安全、支付和資料目錄需要明確責任人。請說明如何用 CODEOWNERS 配合分支保護或規則集，實現可發現、可執行、可稽核的審批流程，並處理例外和團隊變更。
面試官考察點
- 是否區分 CODEOWNERS 的自動請求與分支保護中的必需審批。
- 是否核對程式碼所有者的寫入權限、可見團隊、目標分支和檔案位置。
- 是否能處理 CODEOWNERS 自身保護、fork、草稿 PR、規則繞過和審批陳舊。
- 是否用覆蓋率、合併阻斷率、等待時間和稽核記錄衡量治理效果。
回答前需要釐清的問題
- 哪些目錄必須阻斷合併，哪些只需要通知？是否存在緊急修復路徑？
- 責任人是個人還是團隊？團隊可見性、寫入權限和成員輪換如何維護？
- 保護哪些分支？規則集與經典分支保護是否同時存在？誰可以繞過，繞過是否留痕？
- 如何處理 CODEOWNERS 檔案本身、fork、草稿 PR、審批陳舊和離職成員？
30 秒回答框架
我會先繪製關鍵目錄與責任團隊，再把 CODEOWNERS 當作匹配和通知層，把分支保護或規則集當作合併阻斷層。驗證所有者具備寫入權限、團隊可見且檔案位於目標分支；保護 CODEOWNERS 自身，定義緊急繞過和稽核。上線前用模擬 PR 覆蓋新增、移動、刪除和 fork 場景，監控審批等待、阻斷率、繞過次數和孤兒路徑。
分步驟深入解答
1. 定義責任邊界
按風險和變更頻率劃分目錄，避免用一個全域團隊覆蓋所有檔案。每條模式都應有明確 owner、備用 owner 和失效時間，定期檢查沒有匹配者的路徑。
2. 分離請求與強制執行
CODEOWNERS 會在相關檔案被修改時自動請求審核，但只有啟用必需 code owner review 的分支保護或規則集才會阻止合併。把兩層分別測試，避免「收到通知」被誤認為「無法合併」。
3. 保護設定與例外
把 CODEOWNERS 放在受保護位置，並為它指定 owner。對緊急修復定義最小權限繞過、理由欄位和事後複核；處理草稿 PR、fork 和新推送導致審批陳舊的情況。
4. 營運指標與遷移
先在報告模式稽核匹配率、孤兒路徑、等待時間和誤阻斷，再逐步開啟必需審批。團隊成員變更和儲存庫遷移時同步更新權限、規則集和稽核查詢，保留回滾方案。
高品質示範回答
我會先按風險劃分目錄和責任團隊，建立帶備用 owner 的 CODEOWNERS，並檢查團隊可見性和寫入權限。然後明確 CODEOWNERS 負責匹配與通知，分支保護或規則集負責真正阻斷合併；兩層都用模擬 PR 驗證。CODEOWNERS 檔案自身放在受保護目錄並指定 owner，緊急繞過採用最小權限、理由和事後複核。上線先以報告模式測量孤兒路徑、誤阻斷和等待時間，再逐步強制執行；持續監控陳舊審批、繞過次數和規則覆蓋，並在成員或分支變化時複核。
常見錯誤
- 以為 CODEOWNERS 自動請求審核就一定會阻止合併。
- 忽略團隊必須可見且擁有寫入權限。
- 沒有保護 CODEOWNERS 自身，導致治理規則可被單獨修改。
- 忽略目標分支、fork、草稿 PR 和陳舊審批。
- 沒有定義緊急繞過、事後複核和稽核留痕。
- 只看審批數量，不看孤兒路徑、等待時間和誤阻斷。
追問及應對
多個 owner 是必須全部批准嗎？
通常任一匹配 owner 的批准即可滿足 code owner review，除非另有規則。產品設計應明確高風險目錄是否需要額外的多方審批規則。
為什麼要保護 CODEOWNERS 檔案本身？
否則貢獻者可以先修改所有權映射，再修改關鍵程式碼，繞過原本的責任邊界。為設定檔指定 owner 並要求審批能減少這條繞過路徑。
如何降低輪換成員造成的阻斷？
使用可見團隊而非個人，設定備用團隊和變更檢查；成員離職或權限變化時自動稽核孤兒路徑，並在規則生效前完成替換和回歸 PR。