三、发布分支模型 

    传统标准以一系列连续的基线来管理软件配置。发布分支模型的代码管理就是这种方法。在这种传统模型中，发布工程师提交一个新版本时，建立一个新分支，该新分支作为继续开发的基线，如图1所示，旧分支包括已发布的版本，亦即实际的历史基线参考点。该分支被遗留下来，不再起作用。

    发布分支模型提供SCM按惯例所需要的一系列连续基线，为开发人员提供了更改代码时可采用的共用基准。但是，它有两个明显缺点：要求顺序更改代码，如顺序检入和检出，而不能并行开发；增加了对已发布版本的维护复杂性和费用。

    发布分支模型很容易理解，但修复老版本软件的缺陷很可能丢失在后续版本中执行的更改。只要存在产品维护，就有缺陷修复和进行应急发布的可能性。在这种情况下，开发人员必须在老分支中进行修复并依此产生新版本。这看起来很简单明了，但要保证修复的缺陷不再出现在后续版本的操作很复杂，因为开发人员必须将该缺陷修复传递给各后续分支，以保证后续的从来没有修复该缺陷的工作流版本中不再出现该程序缺陷。

    隔离更改并确认将每个缺陷修复都传递给所有后续版本会增加交流和协调负担。当开发人员从一个开发流转到另一个新版本的开发流时，环境在不停地发生变化。发布分支模型不支持长期的并行开发发布周期，在发布之前，所有检出的代码必须再检入。如果开发人员在发布之前不检入所有的代码，那么在发布后，该模型方式就不允许代码从头构建。每当开发人员在发布后检入更多更改时，发布工程师就必须保证这些未经测试的更改不会并入由该工作流创建的后续各新版本中，这些新版本可能因诸如应急发布之类的原因发布。由于没有从头构建，大大地增大了应急发布错误构件的风险，因此这种发布特别容易出问题。这也破坏了整体基线概念，因为，从未对外发布的更改进入了基线代码。

    发布分支模型也不能维护多个并存版本。

    在发布分支模型应用中，经常按缺陷管理构建，容易引发称为缺陷构建综合症的问题。图2显示了按缺陷构建所面临的困难。发布工程师必须手工确定与指定缺陷修复相关的代码并确保只有该修复相关的代码进入发布构建。在这种模式下，版本控制工具要求必须将代码检入到原先检出的同一工作流。如果开发人员在发布软件产品之前没有将代码检入回去，就不能将该代码直接用于下一个版本的工作流。必须首先执行这种回原工作流的滞后检入，然后再合并到后面的工作流。否则，要求开发人员放弃这些更改并在新的开发流重新更改。