選擇 Taiga 在哪裡等待決定

區分四項決定

虛構設備服務有四項不同決定：接受計畫、執行建置、合併變更，以及部署。不要把一個開關當成四項操作的全部授權。

改變自主性前，檢查儲存庫管線在合併後會做什麼。如果合併到工作分支會觸發部署，自動合併也可能觸發該既有流程。

決定計畫是否等待

產品設定 Build on its own by default 控制完成的計畫直接進入建置，還是等待核准。計畫需要先由人員決定時，就關閉它。

Initiative 的 Build on its own 設定，可以為該項工作改變此行為。排入工作前，同時檢查預設值和個別選擇。

Approve 以核准者身分開始建置，並受其目前權限限制。計畫失敗不會啟動建置。自動建置本身，不授權合併產生的 PR。

了解合併層級

自主合併獨立控制，啟用前預設關閉。文件載明的整合支援 GitHub，包括 GitHub Enterprise。

組織或工廠上限若停用，下層無法覆寫。產品預設關閉則不同：只要上限允許，initiative 可以啟用自己的合併設定。

對設備服務，明確保留初始範圍。在允許邊界內，後果較小的 initiative，可以採用與員工存取控制變更不同的選擇。

讓必要審查能強制落實

Taiga 會詢問原始碼管理提供者，該 PR 是否可以合併。分支保護決定必要檢查、審查和其他條件。自主合併不會略過這些規則。

如果自動審查必須阻擋合併，就透過儲存庫支援的設定，將結果設為必要狀態檢查。建議性結果，不會因為你期待它必須通過，就自動變成強制要求。

也檢查必要人工核准。政策要求的核准，不能用綠色檢查取代。確認實際目標分支上的規則。

理解停止合併的原因

閱讀 initiative 上的原因。檢查等待中、缺少核准、衝突和計畫未完成，需要不同處理。修正若改變了讓失敗檢查轉為通過的判定條件，Taiga 也會停止自主合併。直接審查該變更。

不要只因必要檢查阻擋進度，就移除它。檢查若一直沒有回報，修正設定，或使用已授權的政策流程。每次修正後，檢查目前 commit。

將部署授權分開

Taiga GitHub App 執行自主合併，並被記錄為合併者。儲存庫管線保留既有部署行為。

在本情境中，合併會部署到預備環境。正式環境仍需要組織的正式環境決定與證據。確認管線會落實這項區分。繼續閱讀交付審查。