git - git-flow merge 是否适合大型团队？

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

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

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

最佳答案

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

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

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

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

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

关于git - git-flow merge 是否适合大型团队？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/16982155/