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