使用gitflow

Question

环境：

• Azure DevOps
• Azure Repos（git）
• 适用于Windows的Git和/或具有Visual Studio Code / Visual Studio Pro 2017/2019的内置git客户端

我们使用的是适用于Azure DevOps的香草gitflow（https://nvie.com/posts/a-successful-git-branching-model/）：

1. 从[develop]中创建功能分支
2. 通过合并请求将合并功能分支压缩到[develop]
3. 从[develop]的负责人处删除预发行分支[release / n.n.n]
4. 通过拉取请求将[release / n.n.n]合并到[master]
5. 标记生成的合并提交以发布到生产中

此存储库已经看到了一些历史记录（出于双关语意）-它已从github迁移到Bitbucket到Azure Repos，并且在某个时刻，开发人员忘记了进行壁球合并PR，因此历史记录有些混乱。因此，尽管上述步骤4开始显示[release / n.n.n]与[master]之间的合并冲突，我并不感到惊讶，尽管自从先前的[release /]分支进行上一次合并以来，[master]上没有任何更改。我们已经通过在“第4步提取请求”中选择“选择所有传入”来解决这些问题。

让我感到困惑的是，我一直试图阻止这种情况的发生，并且我没有采取任何措施来获得此回购，以使[master]严格落后于[develop]。我尝试过：

git checkout master
git checkout develop
git merge master
git push origin

git checkout master
git checkout develop
git merge --squash -X ours master
git push origin

git checkout master
git checkout develop
git merge --squash -s ours master
git push origin

所有这些似乎都适用于一两个冲刺，但随后我们将再次遇到合并冲突。冲突不在代码行的相同行，相同文件或相同部分中。它们似乎是随机的。

我了解为什么-X ours可能没有按照我的意愿做，但是我真的认为-s ours产生的合并提交将可靠地成为[develop]和[master]的新共同祖先。

我想念什么魔鬼？是壁球合并类型阻止了它的工作吗？

我们还有其他十几个使用相同模型的存储库，但都没有这个问题，因此我假设是该存储库的历史记录已损坏，而不是工具或开发人员滥用git客户端。 [develop]和[master]都受到分支策略的保护，因此任何人都不可能不使用PR来推送它们，并且[master]不会显示不是[release]壁球PR的结果的更改/]分支。