“ 主干开发只需要一根分支。”
上面这句话有没有觉得奇怪，既然是主干开发，为什么还要分支？其实这是历史上出现了多款版本管理工具，带来了不同的说法，从而带来了混淆。在SVN大行其道的时候，SVN的Trunk常见翻译为主干，Branch翻译为分支，而最新Git如日中天，Git里面没有采用Truck这个说法，所有都叫Branch，缺省给出了名为master的Branch，而其实master只是有这个名称，在Git里面并没有特殊地位，完全可以把另外一根分支当成主干。因此在SVN语境里面，主干开发不需要分支，而在Git语境里面，主干开发只需要一根分支，不过这个论述也是有问题的，问题在于主干开发真的限制只有一根分支吗？如果启用了多根短寿命分支，还算不算主干开发？
主干、分支、Master、Trunk、Branch这些词汇有不同理解，在讲述正式内容之前，有必要先说明本文的说法，本文按Git来讲述，约定如下：主干就是master分支，master分支就是主干，单独提到的分支是指除了主干之外的分支，不包括master分支，本文也不建议大家在实际操作当中改变master分支的地位。
虽然当前可以参考GitFlow，GithubFlow等现成的分支方案，但每家组织都有一些特殊情况，未必能够忠实地参照执行，另外在Git强大分支功能的支持下，可以有多种变形，也有灵活应用，因此仍然值得来剖析下主干分支的不同模式。
根据以上说法约定，得到如下主干分支开发3+1大模式
1，先锋主干多稳定分支；
2，守护主干多先锋分支；
3，主干无分支；
4，守护主干单分支。
01
—
先锋主干多稳定分支
在得到一个稳定版本后，将此稳定版本放到一个新分支上，针对此稳定版本的修修补补就在这个分支上进行，新功能不在此分支上开发，而在主干上进行新功能的开发。这是业界采用较多的模式。稳定分支上的有些修改，比如缺陷修复，需要合并到主干， 但有些特定修改，是不需要合并到主干的。这时需要千万注意，合并准确的文件到主干。
对于不能合并到主干的情况，常见的是再拉一个分支，这个分支专门为少数特定情况而用，但从全局讲，可能会导致太多分支，不同分支间混乱，所以这并不推荐。推荐宁愿采用配置开关。
（图片来源于 http://blog.csdn.net/binnacler/article/details/4274486）
比如freebsd的发布就是一个典型的例子。
freebsd的主干永远是current，也就是包括所有最新特性的不稳定版本。然后随着新特性的逐步稳定，达到一个发布的里程碑以后，从主干分出来一个stable分支。freebsd是每个大版本一个分支。也就是说4.x，5.x，6,x各一个分支。每个发布分支上只有bug修改和现有功能的完善，而不会再增加新特性。新特性会继续在主干上开发。当稳定分支上发生的修改积累到一定程度以后，就会有一次发布。发布的时候会在稳定分支上再分出来一个 release分支。以6.x为例，就会有6.0,6.1,6.2…等发布分支。为了避免过多分支，这里最值得注意的是尽早得归并发布分支。
在Git中，Gitflow启用了develop branch，develop的典型用法是新功能合并到develop之后再发布，这属于先锋主干，但要注意，Gitflow是比较灵活的，如果老是在release分支上修改，那么就变成了守护主干多先锋分支。
02
—
守护主干多先锋分支
得到一个稳定版本后，拉出先锋分支，在分支上开发新功能，在主干上进行修修补补。当先锋分支通过一定的测试之后，合并到主干。 可以同时有多个先锋分支，不同的功能可以拉不同的分支，不同发布时间点而又要同时开发的内容必须在不同的分支上。
从发布的角度讲，更推荐将肯定一起发布的内容放在相同的先锋分支上。
主干上永远是稳定版本，可以随时发布。bug的修改和新功能的增加，全部在分支上进行。而且每个bug和新功能都有不同的开发分支，完全分离。而对主干上的每一次发布都做一个标签而不是分支。分支上的开发和测试完毕以后才合并到主干。
这种发布方法的好处是每次发布的内容调整起来比较容易。如果某个新功能或者bug在下一次发布之前无法完成，就不可能合并到主干，也就不会影响其他变更的发布。另外，每个分支的生命期比较短，唯一长期存在的就是主干，这样每次合并的风险很小。每次发布之前，只要比较主干上的最新版本和上一次发布的版本就能够知道这次发布的文件范围了。
03
—
主干无分支
只有主干，没有分支，所有紧急正常的修改全在主干上，开发了一半的东西如果要上线的话，要巧妙的藏起来。对程序的结构提出了高要求，分分合合要方便，开关配置是少不了的了。单从效率讲，这是最高效的模式了。要有不少配套措施才可以。常见的配套措施：每日集成（编译部署测试），静态代码检查，测试不仅仅有单元测试，还有接口测试，还有界面自动化测试。
主干无分支，是不是就是等于现在流行常说的“主干开发”？这个答案还真是不一定。如果考虑2008年前的开发主干和分支情况，典型利用SVN开发，或者利用ClearCase，可以发现，那时很多的情况就是只有主干，没有分支，但那时的开发方式与当前所推荐的“主干开发”就是完全不同的场景。
因此，主干无分支既可以是比较传统的做法，也可以是最激进的做法。
04
—
守护主干单先锋分支
只有一个分支，紧急修改在主干上进行，正常开发在分支上进行，主干和分支根据需要双向同步。需要采用与主干无分支相同的配套手段，而且在主干和分支上都需要建设每日集成，甚至持续集成。这是对比最激进主干开发而言缓和一步的做法。本身属于守护主干先锋分支模式，之所以被笔者故意放成4大模式之一，是因为笔者非常推崇这个分支模式，这个模式拥有主干开发的全部好处，因为两根基线的合并操作非常方便，几乎随时就能操作，而又有一步缓冲，又不至于出现太多分支。
05
—
现实的策略考虑要点
以上分析是理想情况分析，在现实当中，由于都有历史代码和历史版本，实际操作有时往往很难归纳到上述的模式当中，那么这时有如下一个最突出的考虑要点：从哪条基线出品正式投产版本？
常见分类是3类：
1，从master主干出品，
2，从长期固定分支（有些地方叫release branch）出品，
3，从临时成立的版本分支出品，比如ver1.4, ver1.5。
（以上3类都是master为主干，也就是说，第2第3类在出品后都有合并到master的动作。不以master为主干的特别情况不在本文覆盖范围之内，或者对应切换后再来看）
首先3种情况各有针对的情况，没有哪种有截然的优势，都是合理的选择。
其次，真正关键的问题在于除了master主干之外，还有几根长期固定分支，还有几根长寿命分支，普通分支的寿命是多久？ 导向是清晰的：
长期固定分支越少越好，如果存在，那么互相之间的流程要制定的严格并且清晰，最好有自动工具帮助合并；
长寿命分支要务必去掉，这是影响长期开发效率的大敌，一旦存在，如果出现每隔几个礼拜改下，开发团队会很痛苦，测试团队更加痛苦；
普通分支的寿命越短越好，一般而言，结合双周迭代，普通分支的寿命不要超过2周。
最后，从发展和鼓励的方向上，直接从master主干出品是鼓励的，明显的好处在于能够适应更快的情况，而且没有补充动作。
对于前面提出的问题：什么算主干开发？，笔者推荐一个更加清晰的判断标准：除了master之外的所有分支，其寿命都短于2周，合并到master的间隔不长于2天，无论最后投产从哪里出品，无论有多少条分支。
----全文完，以下欣奔敏捷星球介绍----
笔者自2018年12月开启欣奔敏捷星球，在这里记录敏捷教练一线实战情况，记录最真实的具体实例，积累达600多条内容，覆盖了IT敏捷+业务敏捷+DevOps的诸多细节。
本星球展示了更快交付的敏捷方法：在百人级规模，采用需求流模式，让创意从选择启动到上线只需要一个月时间，快速响应市场变化，更快捕捉市场机会。欢迎朋友们来看看:)
欣奔敏捷星球记录了从IT到业务的敏捷实践以及DevOps建设实战情况，提供最鲜活的真实案例。也有成员基于实践情况的提问和解答，星主提供远程教练咨询服务。
目前积累内容包括全套敏捷项目管理教材，ScrumBan欣奔版，需求流模式，DevOps具体解决方案。
