git-flow 合并是否适合大型团队？答案

【问题标题】：Does git-flow merging scale well for larger teams?git-flow 合并是否适合大型团队？
【发布时间】：2013-06-07 10:40:48
【问题描述】：

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

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

这在实践中是否存在问题？有没有在 git-flow 工作方式中合并分支的经验？还是其他一些具有类似好处的分支策略？

【问题讨论】：

您似乎混淆了 git 工作流程和不同人的实际角色。 git-flow 不对谁做什么做任何假设，它只是为分支应该如何发展设定指导方针。谁来做完全取决于你，不一定只有一个人来做所有的合并。
是的，可以轮流做更多的人，但问题仍然存在。一个人负责将稳定分支与为开发该特定周而到达的所有新工作合并。我可以看到这是一个问题。

【解决方案1】：

我一直是我工作的公司内部 git-flow 分支的主要开发人员，并在将其推广到一个由大约 40 名开发人员组成的团队中发挥了重要作用，我们在 3 周的版本中发现了一些实施问题可以同时包含多个项目 + 错误修复的循环。

一般来说，git-flow 工作流运行良好，但是每当您在发布分支上进行强化，同时在“开发”上进行积极开发时，总是有可能出现合并冲突。

缓解这种情况的一种方法是不断将发布分支拉回开发中（有一个 CI 或 CRON 任务来处理这个问题，它不必是手动的）。

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

无论哪种方式，只要您的版本经过精心规划，并且您管理好修复特定错误的方式和时间，那么您就不应该遇到太多合并冲突。

【讨论】：