分支策略和设置

  • 项目

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

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

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

先决条件

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

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

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

配置分支策略

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

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

还可以通过“项目设置”>“存储库”>“策略”>“分支策略”>“<分支名称>”来访问分支策略设置。

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

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

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

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

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

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

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

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

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

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

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

需要最少数量的审阅者

代码评审对于软件开发项目非常重要。 若要确保团队评审和批准 PR，可以要求获得最少数量的审阅者批准。 基本策略要求指定数量的审阅者批准代码，无人拒绝。

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

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

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

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

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

  • 在“推送新更改时”下：
    • 选择“上一次迭代至少需要获得一个批准”，以要求对上次源分支更改进行至少一次审批投票。
    • 选择“重置所有审批投票（不重置“拒绝”或“等待”投票）”，以便在源分支每次发生更改时删除所有审批投票，但保留拒绝或等待投票。
    • 选择“重置所有代码审阅者投票”，以便每当源分支发生更改时删除所有审阅者投票，包括批准、拒绝或等待的投票。
  • 在“推送新更改时”下：
    • 选择“每次迭代至少需要获得一个批准”，以要求对上次源分支更改进行至少一次审批投票。 用户的批准不会计入该用户推送的任何先前未经批准的迭代。 因此，另一个用户需要对上次迭代进行额外的批准。 Azure DevOps Server 2022.1 及更高版本提供“每次迭代至少需要获得一个批准”功能。
    • 选择“上一次迭代至少需要获得一个批准”，以要求对上次源分支更改进行至少一次审批投票。
    • 选择“重置所有审批投票（不重置“拒绝”或“等待”投票）”，以便在源分支每次发生更改时删除所有审批投票，但保留拒绝或等待投票。
    • 选择“重置所有代码审阅者投票”，以便每当源分支发生更改时删除所有审阅者投票，包括批准、拒绝或等待的投票。

选中“需要代码评审”框

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

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

检查链接的工作项

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

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

拉取请求中需要关联工作项的屏幕截图。

拉取请求中需要关联工作项

检查注释解决情况

“检查注释解决情况”策略检查是否已解决所有 PR 注释。

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

检查注释解决情况

有关使用拉取请求注释的详细信息，请参阅评审拉取请求。

选择“检查注释解决情况”，为分支配置注释解决情况策略。

检查注释解决情况

有关使用拉取请求注释的详细信息，请参阅评审拉取请求。

限制合并类型

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

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

限制合并类型

  • 基本合并（无快进）在目标中创建一个合并提交，其父级是目标和源分支。
  • Squash 合并使用源分支中的更改在目标分支中创建具有单个提交的线性历史记录。 详细了解压缩合并及其如何影响分支历史记录。
  • 变基和快进通过在不合并提交的情况下将源提交重播到目标分支来创建线性历史记录。
  • “通过合并提交变基”将源提交重播至目标，并创建合并提交。

注意

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

强制执行合并战略

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

设置合并要求

  • 无快进合并 - 此选项在拉取请求关闭时合并源分支的提交历史记录，并在目标分支中创建合并提交。
  • Squash 合并 - 使用一个 Squash 合并完成所有的拉取请求，使用源分支的更改在目标分支中创建一个单独的提交。 详细了解压缩合并及其如何影响分支历史记录。

生成验证

可以设置一个策略，要求在 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 后立即：当受保护分支更新后，此选项将拉取请求中的生成策略状态设置为“失败”。 将生成重新排入队列以刷新生成状态。 此设置可确保即使受保护分支更改，拉取请求中的更改也能成功生成。 此选项最适合拥有重要分支且变更量较小的团队。 使用繁忙开发分支的团队可能会发现，每次更新受保护的分支时，等待生成完成都会造成中断。
    • 如果 branch name 已更新，则在 n 小时后：如果传递的生成早于输入的阈值，则当受保护的分支更新时，此选项将使当前策略状态过期。 此选项是在受保护分支更新时始终要求生成和从不需要生成之间的折衷。 此选项非常适合在受保护分支频繁更新时减少生成数。
    • 从不：对受保护分支的更新不会更改策略状态。 此值可减少分支的生成数。 关闭最近未更新的拉取请求时，可能会导致问题。

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

  6. 选择“保存”。

当所有者推送成功生成的更改时，策略状态将更新。 如果选择了“更新 branch name 后立即”或“如果 branch name 已更新，则在 n 小时后”生成策略，则在更新受保护分支后，策略状态也将更新，前提是最新的生成不再有效。

状态检查

外部服务可以使用 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/*
  • */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 文件。

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

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

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

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

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

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

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

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

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

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

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

可能还有其他策略（例如“禁止近期的推送者批准自己的更改”），这些策略会阻止你批准自己的更改，即使设置了“允许请求者批准自己的更改”。

如果路径筛选器中的路径既不以 / 开头也不以通配符开头时会发生什么情况？

路径筛选器中既不以 / 开头也不以通配符开头的路径将不起作用，并且路径筛选器将像未指定该路径一样进行评估。 这是因为这样的路径无法与绝对文件路径开头的 / 匹配。