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

Question

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

1. 开发:内部大师
2. 分阶段:客户评论
3. 大师:制作

流程是featureBranch -> Develop -> Staging -> Master

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

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

因此，在创建 PR 之前，我们将 develop pull 到 featureBranch。

现在，当需要将 develop merge 到 staging 或 staging 到 master 时，我们会遇到冲突。我不想直接推送到这些分支，而只能通过 pull 请求。

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

Answer 1

由于两个不同的分支都更改了同一个文件，因此会发生冲突。如果仅对“staging”的提交是从“develop” merge 的，则不会有任何冲突。

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

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

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

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