分支策略和设置

  • 项目

Azure DevOps Services |Azure DevOps Server 2022 - Azure DevOps Server 2019 |TFS 2018

分支策略可帮助团队保护其重要的开发 分支 。 这些策略强制实施团队的代码质量和更改管理标准。 本文介绍如何设置和管理分支策略。 有关所有存储库和分支策略和设置的概述，请参阅 Git 存储库设置和策略。

无法删除配置了所需策略的分支，并且要求请求 (PR) 进行所有更改。

先决条件

  • 若要设置分支策略，你必须是项目管理员安全组的成员，或者具有存储库级别的 编辑策略 权限。 有关详细信息，请参阅 设置 Git 存储库权限。

  • 若要使用 Azure DevOps CLI az repos policy 命令来管理分支策略，请按照 Azure DevOps CLI 入门中的步骤操作。

  • 若要设置分支策略，你必须是项目管理员安全组的成员，或者具有存储库级别的 编辑策略 权限。 有关详细信息，请参阅 设置 Git 存储库权限。

配置分支策略

若要管理分支策略，请选择 “存储库>分支 ”以在 Web 门户中打开 “分支 ”页。

显示“分支”菜单项的屏幕截图。

还可以使用项目设置>存储库>策略分支策略>><分支名称>访问分支策略设置。

具有策略的分支会显示策略图标。 可以选择图标直接转到分支的策略设置。

若要设置分支策略，请找到要管理的分支。 可以在右上角的 “搜索分支名称 ”框中浏览列表或搜索分支。

选择分支旁边的 “更多选项 ”图标，然后从上下文菜单中选择 “分支策略 ”。

显示从上下文菜单中打开分支策略的屏幕截图。

在页面中找到分支。 可以浏览列表，也可以使用右上角的 “搜索所有分支 ”框搜索分支。

显示“分支”页的屏幕截图。

选择 ... 按钮。 从上下文菜单中选择“Branch policies”。

显示从上下文菜单中打开分支策略的屏幕截图。

在分支的设置页上配置策略。 有关每种策略类型的说明和说明，请参阅以下部分。

在“Policies”页面中配置策略。 有关每种策略类型的说明，请参阅以下部分。 选择 “保存更改 ”以应用新策略配置。

显示“策略”选项卡的屏幕截图。

需要最少数量的审阅者

代码评审对于软件开发项目非常重要。 若要确保团队评审和批准 PR，可能需要至少数量的审阅者进行审批。 基本策略要求指定数量的审阅者批准代码，且不会拒绝。

若要设置策略，在 “分支策略”下，将 “需要最少数量的审阅者 ”设置为 “打开”。 输入所需的审阅者数，然后选择以下任一选项：

显示“启用要求代码评审”策略的屏幕截图。

  • 选择 “允许请求者”批准自己的更改 ，以允许 PR 的创建者对其批准进行投票。 否则，创建者仍然可以投票 批准 公关，但他们的投票不会计入最少的审阅者数。

  • 选择“ 禁止最新的推送程序”批准自己的更改 ，以强制实施职责隔离。 默认情况下，对源分支具有推送权限的任何人都可以添加提交并投票支持 PR 审批。 选择此选项意味着最新的推手投票不计票，即使他们通常可以批准自己的更改。

  • 即使某些审阅者投票等待或拒绝允许 PR 完成，即使某些审阅者投票反对批准，选择“允许完成”。 审阅者的最低数量仍必须批准。

  • 在 推送新更改时：

    • 选择 “在上次迭代时至少需要一个审批 ”，要求对最后一个源分支进行至少一次审批投票。
    • 选择 “重置所有审批投票 (不会重置投票以拒绝或等待) 删除所有审批投票，但每当源分支更改时，保留投票以拒绝或等待，
    • 选择 “重置所有代码审阅者投票 ”以在源分支更改时删除所有审阅者投票，包括要批准、拒绝或等待的投票。

选中“需要代码评审”框

  • 如果未选择 请求者可以批准自己的更改 ，则拉取请求的创建者仍可以对其拉取请求进行 “批准 ”投票，但他们的投票不会计入 审阅者的最低数量。
  • 如果任何审阅者拒绝更改，则拉取请求无法完成，除非选择“ 允许完成”，即使某些审阅者投票等待或拒绝。
  • 将新更改推送到源分支时，可以重置代码审阅者投票。 在 发生新更改时，选择“重置代码审阅者投票”。

如果所有其他策略都通过，则创建者可以在所需的审阅者批准时完成 PR。

检查链接的工作项

对于 工作项管理跟踪，可以要求在 PR 与工作项之间建立关联。 链接工作项为更改提供了更多上下文，并确保更新通过工作项跟踪过程。

若要设置策略，请在 “分支策略”下，将 “检查链接的工作项 ”设置为 “打开”。 此设置要求将工作项链接到 PR，以便 PR 合并。 当没有链接的工作项，但允许完成拉取请求时，请发出 “可选 ”警告设置。

在拉取请求中要求链接工作项的屏幕截图。

在拉取请求中要求链接的工作项

检查注释解析

检查注释解析策略检查是否解决所有 PR 注释。

通过将 “检查注释解析 ”设置为 “打开”，为分支配置注释解析策略。 然后选择是将策略设置为 “必需 ”还是 “可选”。

检查注释解析

有关处理拉取请求注释的详细信息，请参阅 “查看拉取请求”。

通过选择“ 检查批注解析”为分支配置批注解析策略。

检查注释解析

有关处理拉取请求注释的详细信息，请参阅 “查看拉取请求”。

限制合并类型

Azure Repos有多个合并策略，默认情况下，允许所有这些策略。 可以通过强制实施 PR 完成的合并策略来维护一致的分支历史记录。

将 “限制合并类型 ”设置为 “打开 ”以限制存储库中允许的合并类型。

限制合并类型

  • 基本合并 (没有快速转发) 在父级为目标和源分支的目标中创建合并提交。
  • Squash merge 在目标分支中创建一个线性历史记录，其中一个提交包含源分支的更改。 详细了解壁球合并 以及它如何影响分支历史记录。
  • 通过 将源提交重播到目标分支（没有合并提交）来创建线性历史记录。
  • 使用合并提交重新base 将源提交重播到目标上，并创建合并提交。

注意

此功能适用于 Azure DevOps Server 2020 及更高版本。

强制实施合并策略

通过在拉取请求完成时强制实施合并策略来维护一致的分支历史记录。 选择“ 强制实施合并策略 ”，然后选择一个选项，要求使用该策略进行拉取请求合并。

设置合并要求

  • 无快速转发合并 - 当拉取请求关闭并在目标分支中创建合并提交时，此选项合并源分支的提交历史记录。
  • Squash merge - 使用 squash merge 完成所有拉取请求，在目标分支中创建单个提交，其中包含源分支的更改。 详细了解壁球合并 以及它如何影响分支历史记录。

生成验证

可以设置一个策略，要求 PR 更改在 PR 完成之前成功生成。 生成策略可减少中断，并保持测试结果通过。 即使你在开发分支上使用 持续集成 (CI) ，生成策略也有助于提前捕获问题。

当创建新 PR 时，生成验证策略会将新生成排入队列，或者将更改推送到面向分支的现有 PR。 生成策略评估生成结果，以确定 PR 是否可以完成。

重要

在指定生成验证策略之前，必须具有生成管道。 如果没有管道，请参阅 “创建生成管道”。 选择与项目类型匹配的生成类型。

添加生成验证策略

  1. 选择+“生成验证”旁边的按钮。

    显示“生成验证”旁边的“添加”按钮的屏幕截图。

  2. 填写 “设置生成策略 ”窗体：

    生成策略设置

    • 选择 “生成”管道。

    • （可选）设置 路径筛选器。 详细了解分支策略中的路径筛选器。

    • 在 “触发器”下， 每当源分支更新) 或 手动时，请选择“自动 (”。

    • 在 “策略要求”下，选择“ 必需 ”或“ 可选”。 如果选择 “必需”，则生成必须成功完成才能完成 PR。 选择 “可选 ”以提供生成失败通知，但仍允许 PR 完成。

    • 设置生成过期，确保受保护分支的更新不会中断打开的 PR 的更改。

      • 立即更新分支名称>时<：此选项将 PR 生成策略状态设置为在更新分支时失败，并重新排队生成。 此设置可确保即使受保护的分支发生更改，PR 更改也会成功生成。

        此选项最适合重要分支很少更改的团队。 在繁忙的开发分支中工作的团队可能会发现每次分支更新时等待生成会中断。

      • 如果<更新分支名称>，则为 n> 小时后<：如果传递的版本早于输入的阈值，则当受保护的分支更新时，此选项将过期当前策略状态。 此选项是受保护分支更新时始终或从不要求生成之间的妥协。 此选项可减少受保护分支频繁更新时的生成数。

      • 从不：汇报受保护分支不会更改策略状态。 此值可减少生成数，但在完成最近未更新的 PR 时可能会导致问题。

    • 输入此生成策略的可选 显示名称 。 此名称标识 分支策略 页上的策略。 如果未指定显示名称，策略将使用生成管道名称。

  3. 选择“保存”。

PR 所有者推送成功生成的更改时，策略状态会更新。

如果在更新分支名称时<立即出现，或者分支名称>>已更新生成策略后 <n> 小时，则当受保护的分支更新时，如果上一个版本不再有效，则策略状态会更新。<

注意

此功能适用于 Azure DevOps Server 2020 及更高版本。

设置一个策略，要求请求中的更改才能使用受保护的分支成功生成，然后才能完成拉取请求。 生成策略可减少中断，并保持测试结果通过。 即使你在开发分支上使用 持续集成 (CI) ，生成策略也有助于提前捕获问题。

如果启用了生成验证策略，则新生成在创建新拉取请求时排队，或者将更改推送到面向分支的现有拉取请求。 然后，生成策略评估生成的结果，以确定拉取请求是否可以完成。

重要

在指定生成验证策略之前，必须具有生成定义。 如果没有 生成定义，请参阅“创建生成定义 ”，然后选择与项目类型匹配的生成类型。

添加生成策略

选择 “添加生成策略 ”并在 “添加生成策略”中配置选项。

生成策略设置

  1. 选择 “生成”定义。

  2. 选择 触发器的类型。 每当源分支更新) 或手动时，选择“自动 (”。

  3. 选择 策略要求。 如果选择 “必需”，则生成必须成功完成才能完成拉取请求。 选择 “可选 ”提供生成失败通知，但仍允许拉取请求完成。

  4. 设置生成过期，以确保受保护分支的更新不会中断对打开拉取请求的更改。

    • 更新时 branch name 立即：此选项在请求请求中设置生成策略状态，以在更新受保护分支时 失败 。 重新排队生成以刷新生成状态。 此设置可确保即使受保护分支发生更改，拉取请求中的更改也会成功生成。 此选项最适合具有重要分支且更改量较低的团队。 在繁忙的开发分支中工作的团队可能会发现，在每次更新受保护分支时等待生成完成可能会造成干扰。
    • 更新数小时后nbranch name：如果传递的内部版本早于输入的阈值，此选项将在受保护分支更新时过期当前策略状态。 此选项是在受保护分支更新且从不需要生成时始终要求生成之间的妥协。 当受保护的分支频繁更新时，此选项非常适合减少生成数。
    • 永不：汇报受保护分支不会更改策略状态。 此值可减少分支的生成数。 关闭最近未更新的拉取请求时，可能会导致问题。

  5. 输入此生成策略的可选 显示名称 。 此名称标识 分支策略 页上的策略。 如果未指定显示名称，策略将使用生成定义名称。

  6. 选择“保存”。

当所有者推送成功生成的更改时，策略状态将更新。 如果已选择更新生成策略，则nbranch name如果已选择更新生成策略，branch name则当更新受保护的分支时，策略状态会立即更新（如果最新生成不再有效）。

状态检查

外部服务可以使用 PR 状态 API 将详细状态发布到 PR。 其他服务的分支策略使这些第三方服务能够参与 PR 工作流并建立策略要求。

要求外部服务批准

有关配置此策略的说明，请参阅 配置外部服务的分支策略。

需要外部服务的批准

外部服务可以使用 PR 状态 API 将详细状态发布到 PR。 其他服务的分支策略使这些第三方服务能够参与 PR 工作流并建立策略要求。

要求外部服务批准

有关配置此策略的说明，请参阅 配置外部服务的分支策略。

自动包括代码审阅者

可以自动添加审阅者来拉取请求，这些请求更改特定目录和文件中的文件，或拉取存储库中的所有拉取请求。

  1. 选择+“自动包含审阅者”旁边的按钮。

    显示“添加所需审阅者”的屏幕截图。

  2. 填写 “添加新审阅者策略 ”屏幕。

    显示“添加新审阅者策略”屏幕的屏幕截图。

    • 将人员和组添加到 审阅者。

    • 如果要自动添加审阅者，但不需要审批才能完成拉取请求，请选择 “可选 ”。

      或者，如果拉取请求在以下之前无法完成，请选择 “必需 ”

      • 作为审阅者添加的每个人员都批准更改。
      • 作为审阅者添加的每个组中至少有一个人批准更改。
      • 如果只需要一个组，则指定批准更改的最小成员数。

    • 指定需要自动包含审阅者的文件和文件夹。 将此字段留空，要求审阅者获取分支中的所有拉取请求。

    • 如果拉取请求所有者可以投票批准自己的拉取请求以满足此策略，请选择 “允许请求者” 批准自己的更改。

    • 可以指定拉取请求中显示的 活动源消息 。

  3. 选择“保存”。

注意

此功能适用于 Azure DevOps Server 2020 及更高版本。

为存储库中的特定目录和文件选择审阅者。

输入路径和所需的审阅者

这些审阅者会自动添加到拉取请求，这些请求会沿这些路径更改文件。 还可以指定 活动源消息。

添加自动审阅者

如果选择 “必需”，则在以下时间之前无法完成拉取请求：

  • 作为路径审阅者添加的每个用户都批准更改。
  • 添加到路径的每个组中至少有一个人批准更改。
  • 为添加到路径的每个组指定的审阅者数批准更改。

自动添加所需的审阅者

如果要自动添加审阅者，请选择 “可选 ”，但不要求其批准才能完成拉取请求。

可以选择 请求者可以批准自己的更改。

当所有必需的审阅者都批准代码时，可以完成拉取请求。

拉取请求状态显示审阅者已批准

绕过分支策略

在某些情况下，可能需要绕过策略要求。 绕过权限可让你直接将更改推送到分支，或完成不满足分支策略的拉取请求。 你可以向用户或组授予绕过权限。 可以将绕过权限的范围限定为整个项目、存储库或单个分支。

两种权限允许用户以不同的方式绕过分支策略：

  • 完成拉取请求时绕过策略 仅适用于拉取请求完成。 即使拉取请求不满足策略，具有此权限的用户也可以完成拉取请求。

  • 推送应用于从本地存储库推送和对 Web 进行的编辑时绕过策略。 具有此权限的用户可以直接将更改推送到受保护的分支，而无需满足策略要求。

显示绕过策略强制权限的屏幕截图。

有关管理这些权限的详细信息，请参阅 Git 权限。

在 TFS 2015 到 TFS 2018 Update 2 中， “免除策略强制 ”权限允许用户具有此权限的用户执行以下操作：

  • 完成拉取请求时，选择加入以替代策略并完成拉取请求，即使当前一组分支策略未满足。
  • 即使该分支设置了分支策略，也直接推送到分支。 请注意，当具有此权限的用户发出将替代分支策略的推送时，推送会自动绕过分支策略，且没有选择加入步骤或警告。

重要

在授予绕过策略的能力时（尤其是在存储库和项目级别）时，请谨慎使用。 策略是安全合规源代码管理的基石。

路径筛选器

多个分支策略提供路径筛选器。 如果设置了路径筛选器，则策略仅适用于与路径筛选器匹配的文件。 将此字段留空意味着策略适用于分支中的所有文件。

可以指定绝对路径和通配符。 示例：

  • /WebApp/Models/Data.cs
  • /WebApp/*
  • *.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 文件。

所需的代码审阅者路径是否区分大小写？

否，分支策略不区分大小写。

如何将多个用户配置为所需的审阅者，但只需要其中一个用户才能批准？

可以将 用户添加到组，然后将该组添加为审阅者。 然后，组的任何成员都可以批准以满足策略要求。

我具有绕过策略权限。 为什么仍然在拉取请求状态中看到策略失败？

始终评估已配置的策略，以便进行拉取请求更改。 对于具有绕过策略权限的用户，报告的策略状态仅为公告。 如果具有绕过权限的用户批准，则失败状态不会阻止拉取请求完成。

为什么“允许请求者批准自己的更改”时无法完成自己的拉取请求？

“需要最少数量的审阅者”策略和“自动包含的审阅者”策略都有允许请求者批准自己的更改的选项。 在每个策略中，此设置仅适用于该策略。 此设置不会影响其他策略。

例如，拉取请求设置了以下策略：

  • 需要至少一个审阅者 需要一个审阅者。
  • 自动包含的审阅者 要求你或作为审阅者加入的团队。
  • 自动包含的审阅者 允许 请求者批准其自己的更改 已启用。
  • 要求最少的审阅者 没有 “允许请求者”批准启用自己的更改 。

在这种情况下，审批满足 自动包含的审阅者，但不需要 最少数量的审阅者，因此无法完成拉取请求。

可能还有其他策略，例如 禁止最新的推送程序批准自己的更改，从而阻止你批准自己的更改，即使设置了 “允许请求者批准自己的更改 ”。