图3所示的目的分支的模型，是一种改良的配置管理模型。利用这种模型，发布工程师可根据特定目的在不影响主要开发流的情况下创建新的专用目的分支。通常，“目的”包括在开发团队之外发布软件及其相关组成元素（如文档）。通常这些发布工作都是工程进度的重大的里程碑标志，如用于Alpha测试或Beta测试等目的进行的QA发布。

    目的分支模型既支持根据常规发布，也支持根据需要进行的受控的紧急发布，它避免了发布分支模型的缺陷构建综合症。目的分支模型可以满足所有的典型的评价标准。该模型还简化开发。开发人员可以工作在相同环境的主要开发分支下，减少了开发团队成员关于在哪儿执行更改的疑惑，使紧急发布更健壮，减少了代码冻结对于团队工作的影响。

    分出一个新的发布分支而不分出一个新的工作分支，避免了发布分支模型的代码冻结，有利于工作进展。因为代码冻结使他们无法检入正在进行的工作，推迟代码冻结通常会导致压缩测试周期、降低发布产品的质量。

    目的分支模型管理要复杂些，主要是因为它要求更为深入地了解SCM和更熟练地使用SCM工具。但这种模型提供了便捷的方法，正如前面所述，发布工程师为发布产品衍生出一个新的分支，而开发工作仍保持在主要开发流上。

    发布工程师可以产生一个QA分支用于发布QA测试产品。一旦开发和测试人员完成了缺陷的发现和修复工作，发布工程师就可以发布产品。发布新版本时，发布工程师建立一个特定生产流分支，该分支的唯一目的就是支持发布。

    目的分支模型假定产品发布周期中有一个里程碑点，到达该点，开发人员不再增加新功能，也不进行未经评估和控制的改进。该里程碑点标志着开发工作已进入代码冷冻阶段。在代码冷冻期间，开发人员在开发流进行缺陷修复并定时发送新版本给QA。每个QA发布版本都有一个对应的分支，方便验证缺陷是否修复及缺陷是否出现在之前QA发布版本中，也方便标识发现缺陷的版本和修复缺陷的版本。

    软件通过测试周期，逐渐稳定，修复工作逐渐减少，可实现代码冷冻到代码冻结。在代码冻结里程碑点，即使该版本只是候选产品，也必须进行最终测试，以确保其可以用于生产，开发团队可假设产品已准备就绪可以用于最终的生产。从这个里程碑点开始，开发人员直接将经更改控制委员会（或工程管理团队）批准了的缺陷修复直接加入到对应的QA分支并合并修复结果到主要开发流。待测试人员验证确认变更代码库正常运行之后，发布工程师就可以发布用于生产的产品并建立生产分支。当外场发现缺陷需要发布紧急版本时，开发团队可以采用同样流程，如图3所示的“产品1.1”。

    五、支持并行开发

    快速开发流行趋势要求进行并行开发。软件项目必须边改进边发布。为了满足并行开发的各种需要，可以建立临时桥接流，一条用于待确定的缺陷修复，一条用于系统改进。也可以只建一条桥接流，既用于缺陷修复又用于系统改进。在候选产品发布后，就可以合并到开发流。

    在发布分支模型中，当正在进行的代码变更必须延迟到发布之后时，就会出现问题。对于孤立的、没有纳入发布的检出，开发人员陷入了两难境地：要么，将更改过的代码检入到原检出流，这就意味着要将其放入发布产品的分支，而该分支不包含此代码，这就破坏了分支的完整性，然后将其合并到一个新的发布分支中；要么，从新分支开始重新检出，重新更改，再检入到新分支，这又引起不必要的重复。

    目的分支模型可以解决这种矛盾，如图4所示，因为主开发流没有改变，开发人员可以检入代码到其被检出的主工作流，并且将其纳入即将发布的产品发布周期。用于发布产品版本1.1的代码库仍保持不变，因为它归属于自己的分支。

    在目的分支模型中，在发布代码冻结后，开发者只能检出代码到主开发流，而不影响发布代码并保持其完整性。

    目的分支更易于满足多个团队并行地工作在多个子项目的复杂情况的需要，分支可以建立完全重复的环境，这种环境下开发人员可以在不影响其它同在一个代码库中进行开发的代码修改和变更测试。建立小的、有目的的、交替的开发流，让开发人员检入代码到适当的临时流，不影响主开发流。

    并行开发概念允许频繁地将更改从一条开发流合并到另一条开发流，目的分支模型能照顾到该需要，SCM和发布流程可以管理这些合并操作，使它们尽可能地不增加操作负担。

    与之相反，发布分支模型的操作基于各版本是线性的和连续的、每个后续版本是其前一版的延续的假设，因此对现存基线版本或之前版本进行更改集成都不太容易，实现这些更改需要付出特殊努力来保证任何老版本的新发布都只包含期望的更改（通常是缺陷修复）而没有其它的更改，而且要求发布工程师正确地将这些更改合并到新的、正在工作过程中的版本以及老版本与当前版本之间的所有版本。

    在目的分支模型中，开发人员建立一条单独的构建主流，在预先确定的时间发布一个产品的新版本，发布工程师建立单独的分支。这种方式允许频繁地在代码主流上从头构建，涵盖所有实现了的更改。如今软件公司最推崇的方法都强调通过从头构建实现频繁的集成。这种构建随着测试人员和开发人员的工作结果检入逐步集成更改，可以连续不间断地构建，直到发布周期结束。这种方法确保了连续的集成并避免了项目组推迟集成引起的大量矛盾的更改可能产生的冲击。

    在完全相同的环境下修改代码，可以连续地进行每条工作流的构建并对更改进行深入的测试，而不影响开发主流。可实现多个开发人员同时对多个代码因多种目的进行多种更改。目的分支模型的变体可以适应各种情况。

    六、结束语

    尽管发布分支模式应用广泛，而且很严格地执行顺序基线的传统标准，但发布分支模型在开发新版本时对已发布的软件老版本维护困难，容易出错，通常需要手工修复已发布软件。它的主要缺陷还包括对已发布代码修复的管理方面的不必要的复杂性，以及在过程中进行不必要的孤立更改，影响集成进度。

    目的分支模式避免了这些缺点。该模式还提供了结构化的机制管理多路工作流，支持提交多个发布版本，并能满足应用并行开发和持续集成的方法来缩短开发周期的需要。

    由此可见，在软件配置管理的分支模型中，基于目的分支的模型更有利于并行开发，既可改善软件常规发布控制，也可改善应急发布控制。基于目的分支的配置管理模型值得推广应用。