如何在长期存在的分支之间保持一致的合并策略？

Question

在我们的 Azure DevOps 项目中，我们有三个长期存在的分支，它们都受到保护，以防止开发人员直接推送到这些分支：

基本上，一个功能是在分支

abc

中开发的，在使用 squash 进行拉取请求审查后合并进行开发。我们时不时地将这次没有挤压从

develop

合并到

staging

并在我们的预生产环境上进行测试。

我们满意后，我们创建一个发布分支，生成变更日志并将更改推送到

main

，也没有挤压。

我们的功能

abc

现已成为主要功能，但现在我们希望将变更日志重新开发。我们需要从

master

合并到

staging

无挤压，然后从

staging

向下合并到

develop

无挤压。

实际上效果非常好。我们唯一遇到的困难是，在合并阶段，我们完成了开发使用挤压的PR，并在合并回阶段不使用挤压完成PR。非常容易出错。

我们如何解决这个问题？

Answer 1

总而言之，您仅在一种情况下在develop分支上使用了

Squash合并

：在分支

feature-abc

中开发了一项功能，在使用squash进行拉取请求审查后合并以进行开发。在其他情况下，不使用 Squash 合并。

在这种情况下，可以创建一个自动运行的管道来确定当前开发分支的拉取请求是否使用 Squash 合并，并根据结果更改限制合并类型策略。

理论上它是这样运作的：

首先，我们需要一个管道，当创建拉取请求时将触发该管道。我们可以参考此处的步骤YAML 管道的基于通用 Webhook 的触发器。我们需要创建传入 WebHook 服务连接和带有事件 A pull request is created in a Git repository. 的 webhook
。
在管道中，我们可以通过
```
${{ parameters.MyWebhookTrigger.resource.sourceRefName}}
```
获取源分支Name。当源分支名称为
```
feature-abc
```
（或包含关键字
```
feature
```
）时，使用Rest API合并策略policy更改带有
```
"useSquashMerge": true
```
的策略。
请注意，您应该避免同时为开发分支创建多个拉取请求。

上述做法可能会增加过程的复杂性。如果您希望它不那么复杂，也许您需要使用一些培训课程来让您的团队成员知道在什么情况下使用哪种合并类型。