http://blog.sina.com.cn/s/blog_74bd788f0101aohh.html
在敏捷开发中，单一主干代码管理经常被提及，那为什么要采用单一主干代码管理？单一主干代码管理带来哪些好处？如何做到持续发布新功能并定期稳定的可商用的版本？
为什么采用单一主干代码管理？
在敏捷研发中的代码管理控制时，我们需要牢记两点[1]
首先，只有频繁提交代码，你才能享受版本控制带来的众多好处，比如及时回滚到最近的无错误版本。
其次，一旦将变更提交到版本控制中，那么团队的所有人都能看到这些变更。由于提交意味着公开，无论修改了什么，都要确保它不会破坏原有的系统，所有每一位开发人员必须谨慎的对待其提交可能带来的影响。
如果在版本控制系统中为新功能建立单独的分支，到某个时间点后，当这些修改内容的质量令人满意了，再将其合并到主干，这个类似“两阶段提交”。这种方式存在以下问题
1. 它违背了持续集成的宗旨，因为新建分支的做法推迟了新功能的整合，只有当该分支被合并时才可能发现集成问题。
2. 如果多个开发者同事分别创建多个分支，问题会成指数增加，而合并过程也会及其负责。
3. 它让重构代码变得非常困难，因为分支往往涉及多个文件，会让合并变得更加困难。
单一主干代码管理带来的好处？
在代码管理时，如果单一主干代码管理，可以给开发团队带来如下的好处。
1. 确保所有的代码被持续集成，只有单一主干才能使得所有开发人员的代码被持续集成。
2. 确保开发人员及时获得他人代码，将开发人员间的影响及时暴露，减少由于沟通不及时带来的隐性问题。
3. 避免项目后期的“合并地狱”和“集成地狱”。
这样的做法可以让开发人员花更多的时间在架构设计和代码优化上，而不是从事代码合并工作。
单一代码管理在已上线软件中存在的问题
那如何在单一主干代码做到持续集成新功能或优化代码，修复现网版本的bug及定期上线最新的商用版本？
在实际开发工作中，单一主干的代码管理在项目新建立期间问题不太大，但是如果项目进入到维护期时，容易引入如下问题，
A. 紧急修复的即时性和版本开发的周期性的矛盾。
B. 版本连续开发中，开发和测试存在时间差，导致无法快速发布稳定的可商用的版本。
图1 研发过程中代码管理的状况
如图1所示，当我们在T0发布现网的版本后，开发人员每天checkin开发的最新代码，但每天开发的代码未必完全能够完成整个用户故事。如果在Tn开始下一版本的预发布，则测试团队在Tn时刻开始测试会遇到如下几种情况
1. 在Tn之前还存在一些没有解决的Bug
2. 在Tn之前还存在没有完全开发完成新的用户故事
3. 测试人员在Tn上的版本进行测试，会测试出一些新的bug
在这种情况下，开发人员会不断的checkin新代码，fix bug和完成新的用户故事，同时新checkin的代码可能产生新的bug，这样不断的循环，会导致生成一个稳定的版本变得十分困难而且非常耗时，一般会做法会采用如下方法，
1. 在Tn时刻确保所有的功能已经被开发完成，如果有没有开发完成的功能，所有开发人员等待剩余新功能的开发人员完成工作，完成后再开始测试工作。在测试中一般会采用以下两种方法，
a) 方法一，在Tn时刻为release版本分出分支，测试和研发基于生产的版本分支进行测试和代码开发。
b) 方法二，在Tn时刻不为release版本生产分支，所有开发人员停止新功能的研发工作，只完成测试人员测试出来的bug，此过程直到QA通过版本发布为止。
可以通过对以上两种方式分析，存在无法单一主干管理或者导致开发人员无法持续研发新的功能的问题，如果采用方法一还可能导致版本合并的问题。
如何能做到单一代码管理并不影响持续的新功能开发和软件发布？
综上，在敏捷研发过程中，采用单一主干代码管理必须辅助一些规则，才能实现上面提到的矛盾。通过分析主要矛盾集中在持续的开发新功能和定期发布版本的矛盾，而且bug fix是属于小范围改动应该在于可控范围内，所制定规则如下，
1. 新功能开发流程：增加一个打开状态的开关，此开关可以通过developing和developed两个标志来区分研发中，测试中和发布的状况，具体规则如下，
a) 研发状态：研发人员在开发新功能时，需要根据开发进度设置新功能块的状态，例：当新功能处于开发状态时，需要将此功能块设置成developing(开发中)状态。
b) 测试状态：当开发人员开发完毕，并完成本地测试没问题之后，将此功能块从developing状态改变成developed(开发完成)状态，交由测试人员对新功能进行测试。
c) 发布状态：当新功能测试完毕之后，由产品经理和功能负责人一起决定是否发布此功能，如果决定发布，将developed标识从功能模块中去掉，并通过团队评审，进入主干代码。
图2新功能研发代码管理规则
2. 定期发布稳定版本流程：
a) 开始测试预发布版本：
1. 当从Tn时刻开始测试即将发布的版本时，通知所有研发人员，从这个时刻起停止所有新功能的状态变更，但是可以继续研发代码，并每天按照平时一样checkin 代码。
2. 所有的bug fix必须保证全部修复完成后才能checkin 代码（bug一般都能在1-2个工作日内完成修改）
b) 测试中：从Tn这个版本测试出来的问题，研发人员马上进行修复，并checkin到主干代码中，每天测试人员从库里取出编译出的最新版本进行测试（因为新模块的研发通过开关进行了控制，所以新模块的研发代码不会对软件质量造成影响），通过这个机制可以确保每天的代码是高于前一天的代码质量。
c) 完成测试，达到发布标志：当在T（n+m）时刻，如果软件质量达到发布要求，则在此版本号上打上发布版本的Tag，并通知所有开发人员可以重新开启修改developing和developed标志，使新的功能在产品中生效。
3. 紧急修复现网运营版本的Bug：
a) 当系统上报bug后，首先需要对bug进行分析并进行归类，如果不会导致业务无法使用或者crash的bug，则作为一般的日常问题进入产品bug库，尽量不要对现网运营系统进行打补丁。
b) 如果发现了导致业务无法使用或者crash的bug，则找到现网的release版本，并在代码管理库此版本上拉出分支，并在此分支上进行bug fix，解决完成后，将相关代码立即合并会主干代码。
通过以上规则处理，我们在实际敏捷研发中，在代码库规则中整体展现如下图所示
图3 建议的敏捷研发代码管理规则
相关其他工作
此处需要CM进行配合，才能很好的完成测试，研发和产品发布之间的配合，具体规则如下图所示：
图4 代码配置规则
本文提到的代码状态规则需要根据不同的项目和编程语言设计方案，我们在Android和iOS系统研发下采用了if（）{…} else{…}语句进行实现，在struts框架下研发采用返回不同的状态进行控制实现，其他项目的实际控制方法建议根据实现情况进行调整。
[1] Continuous Delivery –Reliable Software Releases Through Build,Test,and Deployment Automation [eng] Jez Humble, David Farley