我的公司合并分支机构错了吗？
最近，我碰到了一篇有关分支和合并以及SCM的MSDN文章：分支和合并入门-Chris Birmele。 他们在文章中说“大爆炸合并”是一种合并的反模式： 大爆炸合并-将分支合并推迟到开发工作的尽头，并尝试同时合并所有分支。 我意识到这与我公司对所有开发分支的工作非常相似。 我在一家非常小的公司里工作，只有一个人担任最终审查+干线合并授权。我们有5个开发人员（包括我在内），我们每个人都会被分配一个单独的任务/错误/项目，我们每个人都将离开当前主干（subversion），然后在我们的分支中执行开发工作，测试结果，编写文档如有必要，请与其他开发人员进行同行评审和反馈循环，然后将分支提交给我们的项目管理软件进行评审+合并。 我的老板是主干存储库的唯一授权，实际上将把分支的所有审核推迟到一个时间点，在该时间点他将尽其所能进行审核，一些分支将被退回以进行增强/修复，有些则被丢弃。分支将直接合并到主干中，由于冲突等原因，一些分支将被退回。 对于我们来说，在最终审阅队列中有10-20个活动分支合并到主干中并不少见。 在最后的审阅和合并阶段，我们经常还必须解决冲突，因为两个分支是在同一主干上创建的，但修改了同一段代码。通常，我们可以通过重新分支，重新应用更改并解决冲突，然后提交新分支进行审核（可怜的人变基）来避免这种情况。 我有一些直接的问题是： 我们是否展示了被称为“大爆炸合并”的非常反模式？ 我们看到的某些问题是此合并过程的结果吗？ 我们如何在不增加我老板的瓶颈的情况下改善这一合并过程？ 编辑：我怀疑我的老板会放松对中继存储库的控制，还是允许其他开发人员合并到中继。不知道他这样做的原因是什么，但是我真的不打算提出这个话题，因为这个话题以前被提出过并且很快就被否决了。我认为他们只是不信任我们，这是没有意义的，因为无论如何都跟踪了一切。 任何其他见解这种情况将不胜感激。