创建一个单独的yaml管道，其中包含合并前的构建步骤，然后在PR策略中为其设置这些步骤。它将始终从创建PR的当前分支运行代码。
我们这样做：（均在同一个repo中）

1. build_steps.yml -包含构建步骤的Yaml模板
2. azure-pipelines-yml -包含build_steps.yml引用以构建项目的主管道
3. pre_merge.yml -仅由PR请求运行的辅助管道，该PR请求具有对build_steps.yml的引用，因此构建中没有差异，并且如果发生更改，则需要更新两个位置。
   整个yaml定义：

#pre_merge.yml
trigger: none #Pipeline should never trigger on any branches. Only invoked by the policy.

variables:
  - name: system.buildConfiguration 
    value: 'Release'

  - name: system.buildPlatform
    value: 'win10-x86'

  - name: system.debug
    value: 'false'

pool:
  vmImage: 'windows-latest'

name: $(SourceBranchName)_$(date:yyyyMMdd)$(rev:.r)

steps:
- template: build_steps.yml

然后在策略中，您可以像这样设置它：

所有这些也适用于传统管道。您需要创建一个单独的预合并构建管道，该管道可以引用具有主构建管道中使用的步骤的TaskGroup。在这两种情况下，您都不必使用模板或任务组，并手动创建步骤。但是如果将来版本会发生变化，您有两个地方需要更新。

只是把这个作为一个替代方案扔出去。但是，如果需要，可以维护一个既可以进行预合并又可以进行部署的yaml管道。
想要创建一个变量来检测管道是否在“master/main”分支上运行，类似于：

IsMainBranch: $[eq(variables['Build.SourceBranch'], 'refs/heads/master')]

从那里，变量将需要成为后续作业/阶段的条件。我个人不喜欢这种方法，因为它限制了管道的可移植性。此外，它还插入了另一个变量来解释;但是，他认为提供另一种选择是公平。

即使策略失败，具有足够权限的用户也可以覆盖分支策略并完成PR。需要指定覆盖的原因，它将成为PR历史记录的一部分。
存储库或分支上的权限称为“完成拉取请求时绕过策略”，并且在通过复选框完成PR时激活策略的覆盖，该复选框仅存在于具有该权限的对话框中。为了解决一个常见的困惑：设置自动完成时，策略覆盖不可用--仅在实际完成PR时可用。
请参阅绕过分支策略和PR完成的文档。参见Eric L.安德森的博客a full walk-through with screenshots。