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

What should be the branch flow to avoid conflicts when using branch per environment

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

  1. Develop: 内部大师
  2. Staging：客户评价
  3. Master：生产

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

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

因为我们很少推送到 staging、master 分支，所以我们一直在从 develop 分支创建我们的分支。

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

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

我做错了什么？如何解决？

  1. 有冲突是正常状态

  2. 对于合并，您需要解决冲突，否则您可能会丢失使用直接推送所做的更改。

  3. 对于功能分支开发需要解决冲突

  4. 对于开发 -> 暂存 -> 主团队需要审查更改并解决冲突

因为两个不同的分支都更改了同一个文件，所以发生了冲突。如果 only 对“staging”的提交是从“develop”中合并的，则不会有任何冲突。

一对长期存在的分支会发生冲突的常见原因有两个（我将在此处使用“开发”和“暂存”的示例；这同样适用于“暂存”和“主控”。 )

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

两种情况的解决方法是一样的：

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