持续交付--分支策略

《持续交付》中指出，使用分支的情况有三种：
1.为了发布新版本，保证新功能不影响旧版本
2.预研或重构，短期使用，分支最终会废弃
3.对程序做较大修改，可以用短期的分支
对于持续集成来说，第一点值得关注，后面两点主要描述的是开发活动中解决特定问题的可能方案。
对于开发人员之间的代码冲突合并，可以通过代码单一职责的合理划分，不同开发人员完成不同的故事，减少文件的冲突。对于分支冲突合并，更多的分支只能推迟合并地狱发生的时间，后期工作量剧增，开发团队必须面对这个情况。分支产生策略，和分支与发布策略是主要需要关注的。
主干一般是指长期存在的分支，最常见的主干就是master。相应的，分支则表示存在一段周期后会消亡的分支。
书中提出的分支策略有：主干发布、按发布建立分支、按特性建立分支、按团队建立分支。
下面是公司采取的分支原则和策略：

1、分支开发，主干发布
这种模式应用最为广泛，它是指：开发人员在分支上提交代码，当新版本的功能全部开发完成或者已经接近版本发布时间点的时候，才合并到主干，并在主干上进行版本质量打磨。质量达标后，用主干代码发布版本。
注意点见上图，一般要求在发布日期前3天完成分支合并。
2、主干开发，分支发布
这种模式是指：开发人员在主干上提交代码，当新版本的功能全部开发完成或者已经接近版本发布时间点的时候，比如发布时间前第三天，从主干上拉出一个新的分支，在这个新分支上进行版本质量打磨。质量达标后，用分支代码发布版本。后续在分支修改bug，并合并到主干。
迭代运作中后期，上一个迭代在新分支上进行版本质量打磨时，下一个迭代的代码可以提交到主干上，这样，新迭代的开发和上一个迭代的发布就自然的隔离开了。
3、主干开发，主干发布
顾名思义，是指开发人员在主干上提交代码，并用主干代码进行软件交付。
在高频交付模式下，应该允许提交未完成功能的代码，前提是不影响用户的正常使用。为了使未开发完成的功能不影响发布质量，可采用特性开关等技术手段来处理这类问题。
基于这三种基本的分支模式，衍生出了很多其他形式的分支模式，比如：三驾马车模式，Gitflow、GitHubFlow模式等。
经验表明，分支策略和产品版本发布的频率会有一定的相关性。
通常，发布频率极高（比如1天多次）、极低（比如1年1次）的团队会采用“主干开发，主干发布”的策略；
发布频率较高（比如1周1次）、较低（比如3到6个月）的团队会采用“主干开发，分支发布”的策略；
发布频率不高不低（比如2周到1个月）的会采用“分支开发，主干发布”的策略。
一般来说，如果发布周期短于两周，软件团队就应该毫不犹豫的选择“主干开发，主干发布”的策略。
在提倡、鼓励持续集成甚至持续交付的大前提下，选择分支策略的原则可以总结为：
长期存在的分支越少越好，最好只有一条主干。
分支生存周期越短越好，最好在5天以内。
在业务允许的前提下，发布周期越短越好。