我们正在考虑在一个由大约 10 名开发人员组成的团队中采用 git-flow，每周发布时间表。我们的计划是每周一从开发分支分支一个发布分支，并在下周一发布到生产之前稳定它。同时，多个功能可以登陆开发，因此很可能有必要解决开发和发布分支之间的合并冲突。
由于进行合并的人不可能知道所有的代码库并自己解决冲突，我想知道这是否会导致问题。基本上，该人需要与每个开发人员交谈并让他们帮助解决冲突。恐怕这会成为一个瓶颈，变得相当乏味和痛苦。
这在实践中是否存在问题？有没有在 git-flow 工作方式中合并分支的经验？或者其他一些具有类似好处的分支策略？
我一直是我工作的公司内部 git-flow 分支的主要开发人员，并在将其推广到大约 40 名开发人员的团队中发挥了重要作用，我们在 3 周的发布周期中看到了它的实施存在一些问题一次包括几个项目+错误修复。
一般来说，git-flow 工作流工作得非常好，但是每当你在发布分支上进行强化，同时在“开发”上进行积极开发时，总是有可能出现合并冲突。
缓解这种情况的一种方法是不断地将发布分支拉回到开发中（有一个 CI 或 CRON 任务来处理这个，它不必是手动的）。
在发布分支上修复错误时，总是需要一定程度的人工交互。如果您不想不断地拉回发布分支（我们不想），那么您必须考虑要在发布时修复哪些错误，以及在下一个发布之前开发修复哪些错误。
无论哪种方式，只要您的发布经过仔细计划并且您管理如何以及何时修复特定错误，那么您就不应该遇到太多合并冲突。