我的公司合并分支机构错了吗？

最近，我碰到了一篇有关分支和合并以及SCM的MSDN文章：分支和合并入门-Chris Birmele。

他们在文章中说“大爆炸合并”是一种合并的反模式：

大爆炸合并-将分支合并推迟到开发工作的尽头，并尝试同时合并所有分支。

我意识到这与我公司对所有开发分支的工作非常相似。

我在一家非常小的公司里工作，只有一个人担任最终审查+干线合并授权。我们有5个开发人员（包括我在内），我们每个人都会被分配一个单独的任务/错误/项目，我们每个人都将离开当前主干（subversion），然后在我们的分支中执行开发工作，测试结果，编写文档如有必要，请与其他开发人员进行同行评审和反馈循环，然后将分支提交给我们的项目管理软件进行评审+合并。

我的老板是主干存储库的唯一授权，实际上将把分支的所有审核推迟到一个时间点，在该时间点他将尽其所能进行审核，一些​​分支将被退回以进行增强/修复，有些则被丢弃。分支将直接合并到主干中，由于冲突等原因，一些分支将被退回。

对于我们来说，在最终审阅队列中有10-20个活动分支合并到主干中并不少见。

在最后的审阅和合并阶段，我们经常还必须解决冲突，因为两个分支是在同一主干上创建的，但修改了同一段代码。通常，我们可以通过重新分支，重新应用更改并解决冲突，然后提交新分支进行审核（可怜的人变基）来避免这种情况。

我有一些直接的问题是：

• 我们是否展示了被称为“大爆炸合并”的非常反模式？
• 我们看到的某些问题是此合并过程的结果吗？
• 我们如何在不增加我老板的瓶颈的情况下改善这一合并过程？

编辑：我怀疑我的老板会放松对中继存储库的控制，还是允许其他开发人员合并到中继。不知道他这样做的原因是什么，但是我真的不打算提出这个话题，因为这个话题以前被提出过并且很快就被否决了。我认为他们只是不信任我们，这是没有意义的，因为无论如何都跟踪了一切。

任何其他见解这种情况将不胜感激。

一些建议：

• 只要在每个分支中所做的更改足够小，就可以拥有很多功能分支或错误修正分支，这没什么错，您仍然可以有效地处理由此产生的合并冲突。如果您的工作方式可以，那应该是您的标准，而不是MSDN文章。

• 每当分支合并到主干中时，主干应尽快合并到所有开放的开发分支中。这将允许团队中的所有人员在自己的分支机构中并行解决合并冲突，从而减轻主干网守的负担。

• 如果网守不等到10个分支“准备合并到主干”，这将更好地工作-解决最后一次主干集成中的合并冲突始终需要团队花费一些时间，因此最好在相互交织的时间间隔内工作-由网守进行一次集成，由团队重新进行一次合并，由网守进行下一次集成，由团队进行下一次重新合并，依此类推。

• 为了使分支保持较小，这可能有助于将较大的功能拆分为几个较小的任务，并在自己的分支中开发每个任务。如果在实现所有子任务之前该功能尚未投入生产，请将其从生产中隐藏在功能切换器后面，直到完成所有子任务。

• 迟早您将遇到重构任务，这些重构任务会影响代码库中的许多文件-这些文件很可能引起与许多分支的大量合并冲突。可以通过在团队中进行清晰的沟通来确保最佳处理，并确保按照我上面的描述正确处理它们：在重新集成之前先将它们集成到所有dev分支中，然后将其拆分为较小的子重构。

• 对于您当前的团队规模，只有一个网守可能仍然有效。但是，如果您的团队规模不断扩大，就没有办法再聘请第二个网守（或更多）。请注意，我不建议所有人都合并，但这并不意味着只有您的老板才能做到这一点。可能还有一两个高级开发人员也可以担任网守的工作。甚至对于您当前团队的规模，第二个网守可以使您的团队更容易地更频繁地和更早地集成到主干中，或者在您的老板不可用时。

我们是否展示了被称为“大爆炸合并”的非常反模式？

听起来像。

我们看到的某些问题是此合并过程的结果吗？

绝对是

我们如何在不增加我老板的瓶颈的情况下改善这一合并过程？

在我公司，每个开发人员都有合并的能力。我们将“合并请求”分配给另一位开发人员，经历审查/反馈/更新周期，直到双方都满意为止。然后，审阅者合并代码。

等待合并的10-20个分支表明您的过程存在缺陷。如果我们有那么多，所有开发工作将停止，直到将其清除。

从本质上讲，这就是许多开源项目的工作方式，尤其是Linux内核，Linux内核的运行分支比您在任何给定时间都要多。在这些项目中避免大爆炸合并的典型方法是创建另一个分支（或多个分支）以进行持续集成。这是您用来确保所做更改与您的同事一起使用的分支，当网守进行检查时，它会定期重新建立到中继上的基础。

（可选）您可以使用此分支将您自己的多个拉取请求合并为一个大的内聚请求，以供老板检查。Linus Torvalds通常会获取拉请求，这些拉请求已集成了两个或更多级别的深度，并且其大小可能约为一个完整的新文件系统驱动程序。

我同意布朗博士的观点，但我也看到了另一种反模式：

我的老板是主干存储库的唯一授权，实际上将把分支的所有审核推迟到一个时间点，在该时间点他将尽其所能进行审核，一些​​分支将被退回以进行增强/修复，有些则被放弃。分支将直接合并到主干中，由于冲突等原因，一些分支将被退回。

在我谦卑的人中，有一些管理反模式：

1. 他/她是制约团队发展速度的唯一瓶颈。您的总线系数是1. 约束理论说，您应该努力改善链中最慢的部分。
2. 您的经理使您的反馈周期变慢，并降低了团队的敏捷性。你可以每周释放吗？
3. 合并的复杂度随代码量的增加而呈指数增长。与100行进行10合并比1000行中的1行更好。这只是您应该尽快进行操作的原因之一
4. 如果您发现中继线发生故障，您将及时进行处理。这几个分支中的哪个是有问题的
5. 那些应该对它们有更多知识的人应该做出决定。在这种情况下，谁知道更多？我敢打赌，编写代码的开发人员。
6. 如果您的经理在节假日，则无法修复生产中的错误。
7. 您正在重做工作并向后扔分支。这是浪费时间。等待生产的时间也是浪费。

推荐：

• 您的经理需要将责任委派给团队。您需要证明团队成熟，专业。明确表示他们可以信任团队
• 实施一些审查方法。可能是您需要另外两名团队成员的批准。
• 可能正在使用SVN使其变得更加困难。尝试一下Git，看看它是否对您有帮助。更。如果您使用GitHub，则可以使用请求请求机制，以便合并需要一定的投票权。
• 阅读并共享有关敏捷实践，持续集成和DevOps的信息。

在单独的分支中执行要素工作时，除非其中一个分支合并到主干并拉入另一个要素分支，否则您将无法轻松进行任何集成测试。以我的经验，这是Big Bang Merge反模式的主要问题。理想情况下，您将进行功能工作，在功能分支中对其进行测试，将其合并到主干中，然后完成功能。如果尚未合并，则每次将其他任何内容合并到中继中之前，都必须重新访问它。这种反模式的痛苦在于，在开发周期结束时会出现许多集成类型的错误。

因此，您有20个分支。分支1刚刚合并。然后，分支2的开发人员必须将分支1合并到其分支中，以便能够无冲突地合并到main中，然后合并。然后，分支机构3的开发人员必须将分支机构1和分支机构2合并到它们的分支机构中，以便能够无冲突地合并到main中，然后合并。

读者练习：编写一个打印我完整文章的程序:-)

这太疯狂了。您将花费不可思议的时间合并。

考虑到您的工作方式以及您的老板是负责任的控制狂，分支机构本身似乎是问题所在。让每个开发人员直接将部分功能提交到主干中，而不是为每个功能创建一个分支。这将集成的负担分摊到多个较小的步骤（双赢）。Gate keeper可以在开发周期的较早时间内跟踪较小的更改，并且仍然是主要的审阅者。

分支本身是您不希望做的事情，除非您有充分的理由这样做或没有其他选择。您足够小，可以使事物保持更紧密的同步，这将更加轻松和安全。