现代版本控制系统（SCM）的作用已不仅仅是保存历史版本，它还是各软件开发组织利用其分支功能实现多人并行开发，提高生产效率的一种工具。对于稍有历史的软件产品来说，一般都会有代码分支的出现，也常常见到一些历史悠久的产品其错综复杂的分支版本树甚至将产品交付团队拖入“无尽维护”的泥潭。分支的目的是希望“分而治之”，而持续集成的目的是“频繁集成”，这二者之间又有哪些联系呢？

　　在《测试三角形与分段构建策略原则》一文中，咱们说到：由于自动化测试时间较长，Joe的团队实施了分阶段的持续集成。虽然这么做引入了一些风险（比如因提交阶段构建中的测试覆盖面小而不能尽早发现代码中问题），但提高了整个团队的开发效率。而且，Joe会根据实际运行情况，在提交构建和次级构建之间不断调整自动化测试用例集来缓解分阶段构建带来的风险。

　　现在，这个软件游戏平台的第一个版本已经接近完成，马上要进行内测了。团队面临的问题是：“如何做分支管理？持续集成该怎么做？”

　　一、短周期发布分支策略

　　是星期五。下班后，Joe和Alice等主要开发人员并没有马上回家，而是在一个小酒吧里聊天呢。

　　Alice说道：“现在我们一直使用主干开发方式，团队所有人都工作在Trunk上，与之对应的只有一个持续集成环境。下星期要做内测了，我们是不是应该拉一个测试分支，用于修复测试中发现的缺陷，在主干继续开发新功能呢？一旦修复完内测缺陷的话，我们可以在这个分支上进行发布，再把这个测试分支的代码变更合并回主干。像这样。”她拿了一张纸画了出来（如图1所示）。

　　“好啊，好啊。我们分成两个团队，一个在测试分支上工作，修复内测过程中发现的缺陷；另一个在主干上工作，开发新的功能。”Bob回应道。

　　“对于拉分支做测试这件事，我没有疑问。但是，我不同意后再把代码合并到主干上。”Joe说道。“我们一直在使用持续集成实践，目的是尽早集成。为什么要等到发布以后再将测试分支的代码合并回主干，而不是每次修复一个缺陷合并回来呢？每次缺陷修复的代码变更不会太多，所以合并起来很容易。等到后再合并，首先是容易漏掉一些代码，其次是一次合并代码太多，容易出错。所以，我建议下星期拉分支时，为测试分支也建立一个持续集成环境。每次发现缺陷时，都为它写一个测试，加到测试套件中。修复代码提交后，会触发测试分支对应的持续集成构建。一旦构建成功，将其合并回主干。”说完之后，他在Alice画的那张图上修改了一下（如图2所示）。