开发人员应该跨分支合并代码吗？

Question

目前我们有3个分支和主干。如果开发人员在一个分支中进行了更改，那么他们就有责任将该更改合并到其他3个分支，并最终返回到主干。合并顺序上有一个已发布的图表，定期更新。

所以，我们有很多小的合并发生在树枝上。

在过去，我们有一个人剪树枝和做合并回来，主要是从一个分支到主干。如果存在冲突，引起文件冲突的2或3名开发人员将解决冲突。分支和合并策略是由个人处理的，主要涉及将分支送回主干。

个人开发者合并是典型的吗？还是应该由一个人来处理，并在特定的时间间隔内进行协调，以管理分支机构？

Answer 1

这里我关心的是，您让它听起来就像任何签入代码的人都必须盲目地将它签入到多个分支。这是不对的。分支机构的存在是有原因的。签入代码的事件应该发生一次，然后从那里流出来。谁让它流动，并不像在每个步骤中保持有意义和有用的分支一样重要。

在我看来你过去有更好的方法。那么问题是:为什么这种情况会改变？

Answer 2

要求开发人员将代码合并到3+活动分支中可能会大大降低生产力。

另外，相信整个团队在他们的合并中是完美的，这是一个定时炸弹。如果开发人员在合并时不小心，它可以引入(或者从旧的源代码中重新引入)bug。

我使用过的更好的方法之一是基于任务的分支。当任务被分配时，开发人员签出当前的暂存分支并创建一个新的任务分支(以分支的名称作为任务号)。开发人员不负责与其他分支合并，但在完成开发后可能会与暂存分支合并。生产和/或版本化分支合并分别处理.任务分支在通过UAT后才被合并到生产/版本分支中。

Answer 3

创建分支时，您负责将其合并回开发中。(实际上，您将开发合并到您的分支中并修复所有问题，然后应该有一个代码评审，然后构建一个用于测试的版本，当它被测试所接受时，您将开发分支再次合并到您的代码中，然后将它合并到没有冲突的开发中)。

每个人都知道，并非只有他们在做一个项目。因此，他们都希望在他们想要将他们的变化与发展相结合的时候，发展将会被改变。他们知道自己在做什么，所以他们将开发合并到他们的分支中，并对此负责。

有些人显然不喜欢测试一个分支。好吧，我不喜欢将未经测试的代码合并到开发分支中，然后测试它，发现它坏了。因为与此同时，有人从开发分支中分离出来，想知道为什么他们的代码不能工作--因为有人在他们开始工作之前就把它弄坏了。