設定與管理分支政策

Azure DevOps 服務 |Azure DevOps Server |Azure DevOps Server 2022

使用分支政策來保護重要 分支 ，要求在變更合併前進行拉取請求、審查器、建置及其他檢查。 本文說明如何在 Azure DevOps 網頁入口網站及 Azure DevOps CLI 中配置和管理分支政策。 有關可用分支政策摘要及分支指引，請參閱 「關於分支與分支政策」。

欲了解涵蓋分支政策、儲存庫存取控制、提交簽署及實際實作情境的完整安全指南，請參見 「安全倉庫與拉取請求」。

你無法刪除已設定必要原則的分支，且所有變更都必須透過提取要求（PR）進行。

小提示

你可以在本文的後面部分使用 AI 來協助此任務，或參考 啟用 Azure DevOps MCP Server 的 AI 協助功能 來開始。

必要條件

Requirement 詳細資料
Permissions 成為 Project Administrators 安全群組的成員，或擁有儲存庫層級的編輯政策權限。 如需詳細資訊，請參閱 設定 Git 存放庫許可權。
Azure DevOps CLI setup （optional） 若要使用 Azure DevOps CLI 的 az repos policy 命令，請先完成 Get started with Azure DevOps CLI。
CLI 的儲存庫目標設定（可選） 在 CLI 建立或更新政策前，先透過執行 az repos list來識別儲存庫 ID。 為避免重複 --org 和 --project，預設值設為 az devops configure --defaults。
政策依賴關係 在設定 建置驗證之前，先準備好建置管線。 在設定 狀態檢查之前，請確認外部服務或內建整合已經能發布拉取請求狀態。
AI 協助設定（選用） 若要使用 Azure DevOps MCP 伺服器的 AI 協助，請使用 Azure DevOps 服務，啟用 AI 助理中的代理模式，並安裝 Node.js 20.0+。 欲了解更多資訊，請參閱啟用 Azure DevOps MCP Server 的 AI 協助。
Requirement 詳細資料
Permissions 成為 Project Administrators 安全群組的成員，或擁有儲存庫層級的編輯政策權限。 如需詳細資訊，請參閱 設定 Git 存放庫許可權。

開放分支政策設定

若要在 Web 入口網站中開啟分支原則設定：

  1. 選取 [存放庫>分支]。
  2. 找到你想管理的分支。
  3. 選擇分支旁的 「更多選項 」圖示，然後選擇 分支政策。

顯示 [分支] 功能表項的螢幕快照。

你也可以從 專案設定>存放庫>原則>分支原則><分支名稱> 開啟分支原則設定。

具有原則的分支會顯示原則圖示。 選擇圖示即可直接進入該分支的政策設定。

您可以瀏覽該清單，或在 搜尋分會名稱 框中搜尋該分會。

顯示從內容功能表開啟分支策略的螢幕快照。

在分支的設定頁面上設定原則。 請使用以下章節開啟或更新現有政策。

設定最低審核者政策

要求至少有審查員批准後，拉取請求才能完成。

若要設定原則，請在 [分支原則] 底下，將 [需要最少數目的檢閱者] 設定為 [開啟]。 輸入必要的檢閱者數目，然後選取下列任一選項：

顯示啟用 [需要程式代碼檢閱] 原則的螢幕快照。

  • 選取 [允許要求者核准自己的變更 ]，以允許PR的建立者對其核准進行投票。 否則，創作者仍可對 PR 投票批准，但他們的投票不計入最低審核人數。

  • 選取 禁止最近的推送者批准自己的更改，以強制執行職責隔離。 根據預設，任何擁有來源分支推送許可權的人都可以新增提交和對 PR 的核准進行投票。 選取此選項表示即使最新的推送者通常可以核准自己的變更，他們的投票依然不算數。

  • 請選取 允許完成，即使某些檢驗者投票等候或拒絕 以便即使部分檢閱者投票反對批准，仍允許 PR 完成。 檢閱者數目下限仍必須核准。

  • 在 推送新變更時 底下：
    • 選取 每次迭代至少需要一個核准，以針對最後一個來源分支變更要求至少一個核准票。 使用者的核准不影響該使用者推送的任何先前未核准的版本。 因此，最後一次迭代需要由另一位用戶進行核准。 在 Azure DevOps Server 2022.1 及更高版本中，每次反覆項目都需要至少一個核准。
    • 選取 需要在最後的迭代中至少獲得一個核准，以要求對最後一次來源分支變更至少有一個核准投票。
    • 每當來源分支變更時，選取 重設所有核准投票（不會重設拒絕或等候的投票），以移除所有核准投票，但保留拒絕或等候的投票。
    • 選取 [ 重設所有程序代碼檢閱者投票 ]，以在來源分支變更時移除所有檢閱者投票，包括要核准、拒絕或等候的投票。

如果所有其他原則都通過，創建者可以在當所需數量的審核者核准後完成PR。

需要連結工作項目

針對 工作專案管理追蹤，您可以要求PR與工作專案之間的關聯。 連結工作專案可提供更多變更內容，並確保更新會經過您的工作專案追蹤程式。

若要設定原則，請在 [分支原則] 中，將 [檢查連結的工作專案] 設定為 [開啟]。 合併 PR 時，此設定要求工作項目必須連結至 PR。 將設定設為 可選，在沒有連結的工作項目時發出警告，但允許完成拉取請求。

拉取請求中要求連結工作項目的螢幕截圖。

要求留言解決方案

檢查批注解析原則會檢查是否已解決所有PR批注。

將 「Check for comment resolution 」設為 「On 」以設定你的分支機構的評論解析政策。 然後選擇政策設定為必要或選擇性。

[檢查批注解析] 的螢幕快照。

欲了解更多關於處理拉取請求評論的資訊，請參閱 檢視拉取請求。

限制合併類型

Azure Repos 支援多種合併策略，且預設允許所有合併策略。 為了維持一致的分支歷史，請在 PR 完成時強制使用合併策略。

將 「限制合併類型 」設為 開啟 ，以限制你倉庫中允許的合併類型。

限制合併類型的螢幕快照。

  • 基本合併（不進行快進合併） 會在目標中建立一個合併提交，其父系為目標分支和來源分支。
  • 壓縮合併 會建立一個線性歷史，目標分支只需提交一次，包含來自來源分支的變更。 深入瞭解壁球合併 ，以及它如何影響分支歷程記錄。
  • 變基和快速前進 會建立線性歷史記錄，方法是將來源提交重新套用到目標分支，而不需要合併提交。
  • 變基並合併認可 將來源認可重新套用至目標分支，並同時建立一個合併認可。

設定建置驗證

設定原則，要求 PR 變更必須先成功建置，PR 才能完成。 建置策略可減少中斷，確保測試結果持續通過。 即使您在開發分支上使用持續整合（CI）來提早捕捉問題，構建策略仍可提供幫助。

當你將原則觸發程序設為 自動 時，當你建立新的 PR，或將變更推送到以該分支為目標的現有 PR 時，建置驗證原則會將新的建置排入佇列。 如果你把政策觸發器設為 手動，使用者必須自己排隊建置。 在這兩種情況下，原則都會評估建置結果，以判斷 PR 是否可完成。

重要

在指定建置驗證政策前，先建立建置管線。 如果您沒有流水線，請參閱 建立組建流水線。 選擇符合專案類型的組建類型。

若要新增組建驗證原則

  1. 選取位於+旁的按鈕。

    顯示 [建置驗證] 旁 [新增] 按鈕的螢幕快照。

  2. 填寫 [ 設定組建原則 ] 表單：

    建置原則設定的螢幕快照。

    • 選取 [建置 管線]。

  • 選擇性地設定 路徑篩選條件。 深入瞭解分支原則中的路徑篩選 。

  • 在 [觸發] 底下，選取 [自動（每當來源分支更新時）] 或 [手動]。

  • 在 [原則需求] 底下，選取 [必要] 或 [選擇性]。 如果您選擇 [ 必要]，組建必須順利完成才能完成 PR。 選擇 [ 選擇性 ] 提供建置失敗的通知，但仍允許PR完成。

  • 設定組建到期，以確保受保護分支的更新不會中斷開啟PR的變更。

    • 當<分支名稱>更新時立即：此選項會將 PR 建置原則狀態設定為失敗，並重新排入組建佇列。 此設定可確保即使受保護的分支變更，PR 變更也會成功建置。

      此選項最適合重要分支很少變更的小組。 在繁忙的開發分支中工作的小組，因為每次分支更新都必須等待編譯完成，可能會造成困擾。

    • 在<n>小時後，如果<分支名稱>已更新：此選項會在受保護的分支更新時使當前的策略狀態失效，若通過的構建早於您輸入的臨界值。 此選項是受保護分支更新時一律或永遠不需要組建之間的妥協。 當您的受保護分支經常更新時，此選項可減少組建數目。

    • 永不：受保護分支的更新不會變更原則狀態。 此值會減少組建數目，但在完成最近未更新的PR時，可能會導致問題。

  • 輸入此組建原則的選擇性 顯示名稱 。 此名稱會識別分支原則頁面上的原則。 如果您未指定顯示名稱，原則會使用組建管線名稱。

  1. 選取儲存。

當 PR 擁有者推送成功建置的變更後，政策狀態會更新。

如果您的組建原則為「分支名稱更新時立即」或「分支名稱更新後n小時後」，則當受保護的分支更新且先前的組建不再有效時，原則狀態會更新。

要求進行狀態檢查

外部服務可以使用 PR 狀態 API ，將詳細狀態張貼到您的 PR。 其他服務的分支原則可讓這些外部服務參與PR工作流程，並建立原則需求。

[需要外部服務核准] 的螢幕快照。

要設定狀態檢查政策：

  1. 確保服務能把拉取請求狀態貼到 Azure Repos。
  2. 在 分支政策中，在 狀態檢查中選擇 +。
  3. 在 「狀態檢查」中，從清單中選擇張貼的支票。 如果服務還沒發布狀態，請直接輸入 genre/name 該數值。
  4. 將 政策要求 設為 「必需 」或 「可選」。
  5. 可選擇性地設定 授權身份、 重置條件、 政策適用性及 路徑篩選。
    • 如果政策應該在 pull request 建立時立即生效，則預設使用 Apply 模式。
    • 如果政策應該只在第一個狀態發布後才適用，請使用 條件式 。
  6. 建立或更新一個針對該分支的拉取請求，並確認該政策是否出現在 PR 的 政策 區塊中。

如需了解內建 Azure DevOps Services 檢查及其 genre/name 識別碼，請參閱 可用的提取要求狀態檢查。 欲完整了解外部服務設定，請參見 「為外部服務設定分支政策」。

如果下拉選單還沒顯示新的整合，請先從服務中貼出狀態，然後加入政策，或直接輸入 genre/name 該值。

自動包含審稿人

您可以自動新增檢閱者到更改特定目錄和檔案的提取請求，或到存放庫中所有的提取請求。

  1. 選取 [+ 按鈕]，位於 [自動包含的檢閱者] 旁。

    顯示 [新增必要檢閱者] 的螢幕快照。

  2. 填寫 [ 新增檢閱者原則 ] 畫面。

    顯示 [新增檢閱者原則] 畫面的螢幕快照。

    • 在檢閱者中新增人員和群組。

    • 如果您想要自動新增檢閱者，但不需要核准才能完成提取要求，請 選取 [選擇性 ]。

      或者，如果提取要求無法完成，請選取 [必要 ]，直到：

      • 以檢閱者身分新增的每個人員都會核准變更。
      • 在每個添加為檢閱者的群組中，至少有一位成員核准變更。
      • 如果只需要一個群組，則您指定的最少成員數目須核准這些變更。

    • 指定需要自動包含檢閱者的檔案和資料夾。 將此欄位保留空白，以要求檢閱者取得分支中的所有提取要求。

    • 如果提案請求的擁有者可以投票來核准自己的提案請求，以符合此政策，請選取 允許提案請求擁有者核准自己的變更。

    • 您可以指定 出現在提取要求中的活動摘要訊息 。

  3. 選取儲存。

必要時允許略過原則

在某些情況下，您可能需要繞過政策要求。 略過許可權可讓您直接將變更推送至分支，或完成不符合分支原則的提取要求。 你可以授予使用者或群組繞過權限，並將權限範圍涵蓋整個專案、一個倉庫或單一分支。

兩個許可權可讓使用者以不同的方式略過分支原則：

  • 完成提取要求 時略過原則僅適用於提取要求完成。 即使提取要求不符合原則，具有此許可權的使用者仍可完成提取要求。

  • 在推送 套用至本機存放庫的推送和網路上所做的編輯時略過原則。 具有此許可權的使用者可以直接將變更推送至受保護的分支，而不需要符合原則需求。

顯示繞過策略執行許可的螢幕快照。

如需管理這些許可權的詳細資訊，請參閱 Git 許可權。

重要

授與略過原則的能力時請小心，特別是在存放庫和專案層級。 原則是安全且相容的原始程式碼管理的基石。

使用帶有分支策略的路徑過濾器

多個分支政策支援路徑過濾器。 如果你設定了路徑過濾器，該政策只會適用於符合該過濾器的檔案。 將此欄位留空，以便將政策套用至分支中的所有檔案。

你可以指定絕對路徑（路徑必須以 / 或萬用字元開頭）和萬用字元。 範例：

  • /WebApp/Models/Data.cs
  • /WebApp/*
  • */Models/Data.cs
  • *.cs

你可以用分 ; 隔符來指定多條路徑。 範例：

  • /WebApp/Models/Data.cs;/ClientApp/Models/Data.cs

如果你在路徑前面加上 !，即使這些路徑原本會被包含，也會將其排除。 範例：

  • /WebApp/*;!/WebApp/Tests/* 包含 /WebApp 中的所有檔案，但不包括 /WebApp/Tests 中的檔案
  • !/WebApp/Tests/* 不包含任何檔案，因為一開始未指定任何檔案

篩選的順序相當重要。 從左到右套用濾鏡。

疑難排解分支原則

我可以將變更直接推送至具有分支原則的分支嗎？

除非您具有繞過分支原則的許可權，否則您無法直接將變更推送至具有必要分支原則的分支。 你只能透過 拉取請求來更改這些分支。 如果沒有必要的分支原則，您可以直接將變更推送至具有 選擇性 分支原則的分支。

什麼是自動完成？

已針對提取要求設定分支原則的分支會有 設定自動完成 按鈕。 選擇此選項，將 提取要求設為自動完成，在符合所有原則後即會自動完成。 當您不預期變更發生任何問題時，自動完成會很有用。

何時檢查分支策略條件？

當拉取請求擁有者推送變更及審查者投票時，伺服器會重新評估分支政策。 如果原則觸發組建，組建狀態會設定為等候組建完成為止。

我可以在分支原則中使用 XAML 組建定義嗎？

否，您無法在分支原則中使用 XAML 組建定義。

我可以使用哪些通配符給必要的程式代碼檢閱者？

單一星號 * 可對應任意數量的字元，包括前斜線 / 與後斜線 \。 問號?可匹配任何單一字元。

範例：

  • *.sql 匹配所有具有 .sql 擴展名的 檔案。
  • /ConsoleApplication/* 會比對名為 ConsoleApplication 資料夾下的所有檔案。
  • /.gitattributes 會比對存放庫根目錄中的 .gitattributes* 檔案。
  • */.gitignore 會比對存放庫中的任何 .gitignore 檔案。

必要的程式代碼檢閱者路徑是否區分大小寫？

否，分支原則不會區分大小寫。

如何將多個用戶設定為必要的檢閱者，但只需要其中一個使用者核准？

您可以將 使用者新增至群組，然後將群組新增為檢閱者。 然後，群組的任何成員都可以核准以符合原則需求。

我有略過原則許可權。 為什麼我仍然會在拉取請求狀態中看到政策失敗？

系統總是會評估已設定的政策以進行拉取請求變更。 對於擁有繞過政策權限的使用者，報告的政策狀態僅為諮詢性質。 如果具有略過許可權的使用者核准，失敗狀態不會封鎖提取要求完成。

為什麼我設定「允許請求者自行核准自己的變更」時，卻無法完成自己的拉取請求？

[需要最少數目的檢閱者] 原則和 [自動包含的檢閱者] 原則都有 [允許要求者核准自己的變更] 選項。 在每個原則中，此設定僅適用於該原則。 此設定不會影響其他原則。

例如，您的提取要求已設定下列原則：

  • 需要至少一個檢閱者的需求是一位檢閱者。
  • 自動包含的檢閱者需要您或您所在團隊中的任何人擔任檢閱者。
  • 自動包含的檢閱者 已啟用 允許要求者核准其自身變更 。
  • 需要最少數目的檢閱者 沒有 [允許要求者核准自己的變更 ] 啟用。

在此情況下，您的核准會 滿足自動包含的檢閱者，但不需要 最少的檢閱者數目，因此您無法完成提取要求。

其他政策可能會阻止你自行批准變更，即使設定了 「允許請求者批准自己的變更 」。 例如，禁止 最近一次推送變更的人核准自己的變更。

如果路徑篩選器不是以 / 或萬用字元開頭，會發生什麼情況？

在路徑篩選器中，任何不是以 / 或萬用字元開頭的路徑都不會生效。 路徑過濾器的評估方式就像那條路徑沒有被指定一樣。 此類路徑不能與/的絕對檔案路徑開頭相匹配。

使用 AI 來配置和管理分支政策

如果你設定 Azure DevOps MCP 伺服器，可以使用自然語言收集儲存庫、分支、拉取請求，並在更新 Azure DevOps Services 的分支政策前建立上下文。

Azure DevOps MCP 伺服器需要Azure DevOps服務、AI 助理中的代理模式，以及 Node.js 20.0+。 目前的 MCP 文件並未說明直接的分支政策讀寫動作，因此請使用 Azure DevOps 網頁入口網站或 Azure DevOps CLI 來建立和更新政策。

任務 範例提示
在儲存庫中列出分支 List the branches in repo <Contoso.Web> in project <Contoso>
在收緊政策前，先檢視拉取請求 What pull requests require my review in project <Contoso>?
檢查提取要求和已連結的工作項目 Get details for pull request <67> and its linked work items in project <Contoso>
在設定建置驗證要求前，先檢查建置狀態 Get the latest build status for pipeline <Contoso-CI> in project <Contoso>

Note

如果你使用 Visual Studio Code，代理模式對於在更新分支政策前蒐集專案上下文特別有幫助。

相關內容

  • Last updated on