代码分支管理：主干发布分支开发的子类型
大家好，我是rainbowzhou。
上篇文章代码分支管理中，我介绍了3种常见的分支开发模式。今天和大家细聊一下，其中的主干发布，分支开发的两种子类型。
引言
根据DevOps研究评估组织(DORA)连续多年对互联网公司的IT效能的调研，全球数千家公司参与了该项调查，其中关于代码配置管理的内容，值得我们思考。
根据以往数年的经验，在高效能研发团队中，相比长期存在的特性分支，基于主线的小批量研发分支更加受到欢迎，行业中的很多先驱者倾向于把工作置于分支上。调查结果表明，以下开发实践可以显著帮助软件交付变得更加高效：
- 每天向主干合并一次代码；
- 让分支生命周期尽量短(少于一天)；
- 同一时间少于三条的活跃分支。
说说我对上述实践的理解，想要成功使用主干发布，分支开发的这种模式，那么首先要让主干尽可能一直保持在可发布状态，其次每个分支的生命周期应该尽可能短，然后主干代码尽早与分支同步，最后一切以主干代码为准，尽可能不要在各特性分支之间合并代码；
分支开发主干发布模式，按照分支存在的周期和目的，可进一步分为：特性分支模式和团队分支模式。
特性分支模式
什么是特性分支模式？
在开发过程中，允许多个开发分支同时存在，且每个分支对应一个功能特性的开发工作。当该特性开发完成后，立即合入主干，其他尚未合入主干的特性分支需要从主干拉取主干代码，与自己分支上的代码进行合并后，才能再合回主干。这种模式为特性分支模式。
特性分支模式的优劣势？
该模式的目的是：让团队更容易在“特性”这个层次上并行工作，同时保持主干的稳定可发布状态。其优势在于每次发布的内容调整起来比较容易。假设某个新功能或者缺陷在版本发布时间点之前无法完成，则不必合入主干中，也不会影响其他功能的发布时间点。
不足：如果特性分支过多，会带来比较多的合并成本。
例如，每当某个特性分支开发完成打算合入主干时，都需要与主干的代码合并，并进行质量验证。一旦主干代码的质量验证通过，其他分支此时都应该从主干上拉取最近的通过质量验证的新代码。否则，如果在特性开发完成后再与主干合并，那么这种一次性合并会带来较大的工作量和质量验证工作。
常见场景
如果有多个特性同时开发完，怎么办？
方法A：所有已完成的特性分支一同向主干合并，然后共同设法让主干代码达到可交付状态。通常该方式不被研发团队采纳，原因是太多的分支一起合并，多方的代码混合在一起，一旦出现了问题，定位问题的难度和修复问题的成本都会大大增加高。
方法B：所有已完成的特性分支排队，以顺序的方式合入主干。好似流水线一般，每个特性分支向主干合入代码后，必须使主干代码达到可交付状态后，才能再合并下一分支特性。这样才能发挥特性分支的优势。但是随之而来的问题是，多个特性分支按排队顺序进行合并，会导致排在队尾的分支等待较长时间。
那么如何减少特性分支的等待时间呢？
可以参考下面的方式：
- 对要合并的特性分支做一次最短路径依赖分析，即无前置任务优先，执行时间短的任务优先；
- 构建流水线时，无关联的任务可以并行；
- 若使用了Docker，可以巧用Docker Cache。若无变动则复用缓存，使得多次重复构建的时间大大缩短。典型的如前端依赖项里的npm install，变更依赖对于高频集成属于小概率事件。因此我们可以在第一次构建时，可以将node_modules这个文件夹打包成为镜像供下次编译时调用。
团队分支模式
什么是团队分支模式？
团队分支可以看作是特性分支的一种特殊情况。即一组人一起在同一个分支上进行开发工作，并且该分支上通常包括一组相近或相关的特性集合的开发。故其分支存续时间比特性分支的存续时间长。
团队分支的适用场景？
该分支模式常见于通信公司的产品研发或大型客户端软件产品研发。成功应用这种模式的关键点在于：
- 每个团队尽早合入高质量的代码，即使不马上发布；
- 向主干合入代码后，尽快使其达到可交付状态；
- 其他团队尽早从主干拉取可交付状态的代码，与自己分支的代码合并。
以上，有任何想法都欢迎大家后台私信我，一起探讨交流。
如果文章对你有帮助，记得在看、点赞、转发、加关注哦！