git-flow合并对于更大的团队来说可伸缩性好吗？

Question

我们正在考虑在一个由大约10名开发人员组成的团队中采用git-flow，每周发布一次。我们的计划是每周一从开发分支分支一个发布分支，并在下周一发布到生产之前稳定下来。同时，多个特性可以在开发中落地，因此很可能有必要解决开发和发布分支之间的合并冲突。

由于进行合并的人不可能知道所有的代码库，也不可能自己解决冲突，我想知道这是否会导致问题。基本上，这个人需要与每个开发人员交谈，让他们帮助解决冲突。我担心这会成为一个瓶颈，变得相当乏味和痛苦。

这在实践中是一个问题吗？有没有在git-flow风格的工作中合并分支的经验？或者其他一些具有类似好处的分支策略？

Answer 1

我一直是我工作的公司内部git-flow分叉的主要开发人员，并帮助将其推出到一个由大约40名开发人员组成的团队中，我们发现它在3周的发布周期内的实现存在一些问题，可以同时包括几个项目+错误修复。

一般来说，git-flow工作流工作得非常好，但只要你在发布分支上进行强化，同时在“开发”上进行积极的开发，总是有可能出现合并冲突。

缓解这个问题的一种方法是不断地将release分支拉回到develop (有一个CI或CRON任务来处理这个问题，它不需要手动执行)。

在发布分支上修复bug时，总是需要一定程度的人工交互。如果你不想不断地拉回发布分支(我们不想)，那么你必须考虑在发布时修复哪些bug，以及在下一个发布之前在开发中修复哪些bug。

无论哪种方式，只要您的发布是仔细计划的，并且您管理如何以及何时修复特定的bug，那么您应该不会遇到太多的合并冲突。