Question

我们正在使用Azure DevOps在我们的项目中采用gitflow流程。我有以下几种情况：

将功能分支合并到Develop中时，我想在完成拉取请求时实施壁球合并策略
当Release分支定期同步回Develop时，我要强制执行no-ff合并，以保留Release分支签入历史记录

有两个问题：

鉴于上述两个要求，这是否表明我可能在分支和合并方面做错了事
AzDo中是否有一个基于源分支提供（自动）不同合并策略的工具？

谢谢

Answer 1

我看不到上述分支和gitflow进程合并的任何问题。请查看此文档以获取有关gitflow process的更多信息。

没有直接方法可以基于源分支自动选择不同的合并策略。解决方法是您可以使用pull request update rest api将pr设置为autoComplete并根据源分支设置合并策略。以下是供参考的示例。

1，首先创建一个构建管道，并添加一个powershell任务以在脚本下面运行。您可以检查here中有关创建经典ui管道的步骤。对于yaml管道，您可以检查此document。

下面的脚本将根据 System.PullRequest.SourceBranch并为此项目启用自动完成功能。这样，当满足所有要求时，pr将自动完成。（您需要根据需要更改if(){}部分）。

    $uri = "$(System.TeamFoundationCollectionUri)$(System.TeamProject)/_apis/git/repositories/$(Build.Repository.ID)/pullrequests/$(System.PullRequest.PullRequestId)?api-version=5.1"

    $response =  Invoke-RestMethod -Uri $uri -Headers @{authorization = "Bearer $(System.AccessToken)"} -Method get 
    $userid = $response.createdBy.id
    $merge =  "rebaseMerge"

    if("$(System.PullRequest.SourceBranch)" -eq "refs/heads/release"){$merge =  "noFastForward"}

    $body =@{
        autoCompleteSetBy = @{
        id= "$($userid)"
          }
        status = "complete"
        completionOptions= @{mergeStrategy = $merge}
     }
    $bjson = $body | ConvertTo-Json

    Invoke-RestMethod -Uri $uri -Headers @{authorization = "Bearer $(System.AccessToken)"} -Method patch -ContentType application/json -Body $bjson

2，然后为Develop分支配置branch policy。并选择上面创建的管道来设置build validation。通过设置构建验证，pr将触发运行在上一步中创建的构建管道。上面的管道将根据源分支更改合并策略。

您也可以submit a feature request（单击“建议功能”并选择“天蓝色”开发人员）为此工具进行Microsoft开发。

Answer 2

我认为目前在 ADO 中是不可能的。我找到了一个功能请求票，并留下了我的评论和建议 - the feature request。

这是我的评论的副本：

I think this feature would be awesome. Currently, is a stack overflow related to this problem:

https://stackoverflow.com/questions/60106638/different-merge-strategies-automatically-based-on-the-source-branch
Also, I’ve checked both UI and REST API looking for a way or a workaround to achieve this but to no avail.

My generalized suggestion would be to be able to create and attach ad-hoc policy to a PR to override a branch policy. This would allow a third party tool (and/or in UI) to override policy properties like “Limit merge types” based on PR properties like ‘source branch’. For instance, if a source branch is set to “feature/somefeature”, “Limit merge types” should be Squash only. Another example, if a source branch is “integration”, don’t allow Squash Merge.

作为替代方案，您可以使用 ADO Service Hooks 在 PR 创建/修改（例如 Azure Functions）时触发自定义应用程序，以留下评论提醒开发人员不要使用 Squash 合并类型。仅当 PR 的源分支是特定分支时，应用程序才能具有添加评论的逻辑。如果您的分支策略设置了 Check for comment resolution，开发人员将无法在不解决评论的情况下完成 PR。这不是你想要实现的（没有什么可以阻止开发人员使用无效的合并类型），但是，希望会减少这种情况的数量。 Here is an example of a custom branch policy in Azure Functions。

基于源分支的不同合并策略（自动）

2 个答案: