每个环境使用分支时避免冲突的分支流程应该是什么

Question

目前，我们有以下分支机构：

1. Develop：内部主控
2. Staging： 客户评论
3. Master： 生产

流量为featureBranch -> Develop -> Staging -> Master

我希望不允许直接推送到这些分支中的任何一个，而只能通过拉取请求。

由于我们很少推送到staging,master分支，因此我们一直从develop分支 创建我们的分支。

因此，在创建 PR 之前，我们develop从featureBranch.

现在，当需要合并develop到staging或stagingto时master，我们会发生冲突。我不想直接推送到这些分支，而只能通过拉取请求。

我究竟做错了什么？如何解决这个问题？

Answer 1

由于两个不同的分支都更改了同一个文件，因此会出现冲突。如果“staging”上的唯一提交是从“develop”合并的，则不会有任何冲突。

一对长期分支会发生冲突有两个常见原因（我将在这里使用“develop”和“staging”的示例；这同样适用于“staging”和“master”。）

1. “分期”方面有一些变化，但“开发”方面没有变化。有时，您可能需要在测试“staging”分支时修复某些内容，因此您可以将其直接合并到“staging”分支。在某些时候，这种变化也需要“发展”——否则每次有人在那里测试时它都会被破坏。为了让 git 知道它存在于两者上，这需要从“staging”到“develop”的合并，而不仅仅是应用相同的更改。
2. 您使用了错误的合并类型。如果您使用“挤压合并”，git 会完全忽略正在合并的分支的历史记录，并创建包含其所有更改的单个提交。有些人喜欢这样做是为了保持他们的历史记录“整洁”，但你永远不应该将挤压合并与你将继续使用的分支一起使用。因为压缩的提交不引用另一个分支的历史记录，所以git 不知道这些更改已经在两个分支上，因此当您再次合并时，它会尝试再次应用它们。

两种情况的解决方案是相同的：

1. 合并从“暂存”到“开发”的所有变更，并解决那里的冲突。每当您对并非来自“开发”的“暂存”进行更改时，请重复此操作。
2. 确保对该合并以及“开发”和“暂存”之间的所有未来合并使用“真正合并”/“合并提交”。