前言

在阿里工作时使用的各种系统，仿佛像空气和水一样，仿佛是理所应当就应该在那里的。但是在离开之后，了解其他人其他公司遇到的困惑与烦恼的时候，才发现这些其实都是大量试错之后宝贵的最佳实践，希望分享给大家。

开发流程

1. 开发同学从AONE（内部项目管理平台）新建一个变更。（AONE同时会从主干拉取一个开发分支）
2. 开发同学将在这个分支上进行开发。
3. 在AONE上集成若干开发分支到测试或预发环境。（AONE会使用或新建一个集成分支用于发布）
4. 发布正式环境之后，AONE会将这个发布分支合并至主干。

这基本上是一个基于GitFlow的分支模式。基于开发分支、集成分支、主干的三驾马车是这个模式的核心。其中的主要区别主要在于集成分支的处理上。
传统的GitFlow模式下集成分支往往只有一个。当研发同学希望到测试环境测试时，就会将自己的开发分支Merge到集成分支中。使得集成分支变得十分臃肿（甚至出现互删代码的惨剧）。而且到了需要发布的时候，由于开发进度的不同，许多在集成分支上的内容并不需要进行发布，又需要进行代码上的拆分，或是重新合并出一个用于发布的分支（其实还涉及到测试有效性的问题，这里不细谈了）。
而在阿里的集成流程中，集成分支是可以有多个的，同一组进入集成的变更会对应一个集成分支。对于上面提到的场景，只需要将集成分支进行切换就可以解决集成问题。甚至有的时候，大家不是同一时间需要去做测试的，沟通好之后，将其他同学的集成退出换成自己的集成分支也将会变得很简单。

版本树示例

场景描述

1. 开发申请了三个变更：dev_a、dev_b、dev_c
2. dev_a、dev_b先进入测试集成环境。dev_c随后也加入测试集成环境。
3. dev_a、dev_b进入预发集成环境（依旧使用release_a_b进行集成）。
4. dev_b更新修复，集成分支合并，预发环境发布。
5. 正式发布，集成分支合并至主干。

补充：其实到这里还有一个重点，开发同学应该尽快同步dev_c的负责同学，主干更新了该变基了。

尾声

软件开发没有银弹，找到痛点并改进，满足实际场景的才是最适合的。当然在没有想法的时候，最佳实践就是起点。