最近，我们转向了“Git Flow”方法，我们使用了develop、release 和main 分支。最近，我们从与最近的release 分支相同的提交中创建了一个main 分支。每次我们将release 分支合并到main 时，我们然后将main 合并到develop，通常使用main 的新分支，我们首先解决冲突（因为它们是受保护的分支）。
然而，随着最新的release 分支从develop 创建，我们在release（此时只是develop）和main 之间存在冲突。解决这些冲突只是一个 0 文件更改 PR，但我不明白为什么首先会有冲突。我绘制了最近的历史来尝试进一步展示这个过程：
请注意，所有这些合并都被压扁
标签： git git-merge git-flow merge-conflict-resolution
如果您使用标准Git Flow，您应该绝不将release 合并到main/master 时出现合并冲突。如果确实有冲突，那就是有问题。不应该存在冲突的原因是因为提交出现在main 上的唯一两种方式是来自release 分支或hotfix。在hotfix 合并到main 的情况下，如果发布分支存在，则应立即将main 合并回release，如果不存在，则应将main 合并回@987654333 @。这样release 将始终领先于main。
使用标准的 Git Flow，唯一可能发生冲突的时候是在合并时：
main 回到 release（修补程序与发布冲突）main 回到develop（发布/修补程序与开发冲突）release 回到develop（发布与开发冲突）
如果您在将 release 合并到 main 时遇到冲突，最可能的原因是您在 main 上有一个修补程序，之后没有立即合并回 release，跳过这一步可能很危险，因为如果您直接将发布分支部署到生产环境，您不会在其中进行那些修补程序更改。
关于图中的这段文字：
在某些时候，试图合并发展为主导致合并冲突。
我假设您的意思是“将
main合并到develop”而不是相反，因为实际上没有develop直接流入main。将main合并到develop时发生冲突是完全正常的，这通常发生在develop和release分支上分支后修改相同文件时。这只是一个正常的开发过程，除非您愿意实现代码冻结。工艺问题：
请注意，所有这些合并都被压扁
这似乎不对。这绝对不是 Git Flow 的一部分，通常你永远不想重写长期/受保护分支上的提交。这意味着在
develop、release、hotfix和main/master上的提交不应被压缩。唯一一次可能如果您不关心功能分支上的特定提交信息，那么在将功能分支合并到develop或release时，将 squash 与 Git Flow 一起使用是有意义的。关于此声明的旁注：
每次我们将发布分支合并到主分支时，我们然后将main合并到develop，通常在我们首先解决冲突的主要分支上使用一个新分支（因为它们是受保护的分支）。
这是一个小问题，但是在将
release合并到main之后，将main合并回develop非常好。标准 Git Flow 建议实际上将release合并到develop而不是从main那里进行合并，但是，从代码的角度来看，它并没有什么不同，并且按照您的方式进行操作是恕我直言，从长远来看更清洁，效率更高。这是我一直向标准 Git 流程推荐的少数几个调整之一。
【讨论】：