拉分支之后，开发团队可以继续开发新的功能。而测试团队可以单独对分支进行测试、部署，不受开发团队的影响。

　　一旦测试中发现问题，载发人员要在该分支上修复。

　　在分支发布之后，一旦发现了严重问题，仅在该发布分支上修复后即可发布补丁版本。

　　在分支上做修改后，要根据实际情况进行分析，是否要合并回主干。如果需要合并，应该立即进行。

　　“那由谁来负责把发布分支中的Bugfix合并回主干呢？”

　　“当然是由Bugfix的人来负责了，他是确保合并正确性的关键。如果Trunk上的代码已被修改，无法合并，Bug负责人要与主干开发人员交流，这个Bug在主干的有效性，然后再决定是否修改，在哪里修改的问题。”

　　“我们要对发布分支上的Bug定义修复标准，尽量在Trunk上修复Bug，除非这个Bug严重影响发布质量。这样可以避免无休止地在发布分支上做代码修改。这样，Bug数才会收敛，发布分支的活跃期才会缩短。”

　　“嗯，相对于我们一直使用的主干开发方式来说，这种短发布分支策略的成本是：

　　需要多套独立的持续集成环境。即每个分支在处于活跃期时，要有与之对应的一套持续集成环境，以便不受影响。

　　每次发布分支上修复缺陷后，只要分支对应的持续集成构建成功，要将其合并回主干。

　　由于主干开发的代码可能因架构改进使原有缺陷不复存在，所以每次合并时都需要人为判断一下合并的必要性。”

　　二、长周期发布分支策略?

　　“哦，我之前工作的一家公司，是用这种分支策略。”Bob说道，“但情况变得非常复杂。版本满天飞，想做合并都不容易。”

　　Joe说道：“我想，可能是因为他们的客户不想升级版本，所以必须在已发布的版本上再发小版本吧？”

　　“的确是这样的。”Bob回答道，“他们的发布周期大约是半年。由于已发布的版本质量不佳，所以总是有紧急修复的版本上线。另外，客户比较担心新版本的稳定性，所以只要满足自己的当前需求，会一直使用旧版本。有些大客户还会要求公司开发针对其自身的特别需求，并快速上线，结果可想而知。”

　　Alice说道：“其实，这已经是短周期发布分支的变形，即有多个活跃分支的长周期发布分支策略（如图3所示）。这种分支策略是应该尽量避免的，它的复杂性和维护成本都很高，因为：

　　每次都要把缺陷修复代码合并到后续的多个发布?分支上，尤其是当该缺陷发生在较老的版本，而当前已有多个活跃版本需要维护时。

　　随着时间的推移，每个分支上的自动化测试用例增多，更多的分支会对持续集成环境中的测试机数量的需求快速增加。

　　发布周期长诱使团队在已有的发布分支上再做子分支(如图3中的R1.1)，这会让集成和验证工作变得更加复杂（如图3中从R1.1到R2.0的Cherry Picking操作表明：需要向多个分支上合并部分代码）。

　　由于每个活跃分支都要对应一个持续集成环境，因此，分支越多，对持续集成环境的维护成本也越高。

　　Bob问道：“有什么办法避免这种糟糕的多活跃分支开发策略吗？”

　　“办法当然有，但不能解决所有问题。”Joe回答道，“比方说，首先，要确保每个版本的开发质量，让客户放心升级。其次，软件产品要支持自动升级。在通常情况下，只要满足需求，用户不会轻易升级软件。所以，要让软件具有自动发现新版本并在后台自动升级的能力。当然，在升级后要通知用户。这样，只要将新版本发布到互联网上的某个服务器上行了。后，也是重要的一点，新版本发布周期要短一些，不断快速地推出新特性，这样可以让用户对产品及研发团队有信心，让客户感觉他们的需求很快会被满足。”

　　“对于那些企业用户来说，这种方法可能不管用。因为，企业内网很少可以连通外网。”Alice说道。

　　“如果是这种情况的话，除了软件本身质量好且能自动无缝升级以外，在销售时可以与客户签订协议，告知所售软件版本的生命周期（比如18个月）以及升级条款，促使企业升级该软件，比如免费的大版本升级，或者因缺陷原因可免费升级等等。”Joe回答道。

　　“嗯，我们开发的是游戏软件平台，部署在互联网上，所以不会遇到这个问题。”Alice说道。

　　Joe微笑着说道：“我们将会面临另外一种问题，即多个小团队开发不同的游戏组件问题。”

　　“哦，对了！现在我们的游戏平台中虽然仅有几个游戏，目前还一起在主干上开发。但在下一版本中，我们会增加大量的游戏组件，那应该如何应对？我们的持续集成环境应该是什么样的呢？”Alice大声地问道。

　　“嗯，是个好问题！”Joe回答道。“我已经有了一些想法。我们内测结束后，再详细讨论吧！时间也不早啦，大家回去休息吧，愉快！”