关注InfoQ，加公众号
接受程序员的技术早餐
作者
编辑|小智
写在前面
在蚂蚁内部，流行着许多有趣的工程实践。 在实践中，有通过工具和过程嵌入集体大环境，不能轻易从外部复制的，也有渗透到日常习惯中，静静遵守的。 例如，分支管理，其实工具和习惯各占一半，是具有蚂蚁特色的成分，适合作为一个例子。 阿里有很多研发团队，事业部使用的发布流程、分支战略虽然不整齐，但整体上是有规律的。 其中有被称为“AoneFlow”的主流发布模型和相应的分支使用方法。 这种工作模式的想法很独特，在蚂蚁以外的地方很少见。 本文以这些实践为中心，谈谈分支管理。
细数分支模式
说到分支管理模式，最常见的是基于干线的模式和GitFlow模式。
基于中继模式是一种推荐的工作方式，可持续集成思想，由单个主干网和多个公共分支组成。 每个公共分支都是在特定版本的提交点上从主干网创建的，用于在线部署和热修复。 在基于干线的模式下，没有显性的特性分支。 当然实际上，Git的分布式特征天生允许所有人都有本地分支。 TrunkBased也并不拒绝短期特性分支的存在。 只是，在说这个模型的时候，大家通常不明确强调那个。
近年来，有很多好案例，但基于干线的模式并未一统天下。 其缺点比较明显，太多的团队同时担任主干，到发布时有可能发生灾难(特别是在多个版本的并行开发的情况下)。 弥补措施是与功能toggle频繁集成和充分的测试覆盖，对开发团队的能力提出了很高的要求。 目前，基于干线的模式主要用于不需要同时维持多个历史版本的SaaS型项目，特别是由微服务改造而成的各种小型服务。
基于干线的模式有两个常见的进化版本。 OneFlow模式借鉴了基于干线的很多思想，对操作流程进行了更为严格的定义，添加了Hotfix分支等内容。 多骨干网模型(通常为双骨干网、固定开发分支和固定发布分支)是干线基础网采用固定发布分支的特例，并在文章中介绍了其如何提高团队的微服务落地能力。 省略说明。
GitFlow模式是一些模式的集合，包括主干分支、开发分支、许多特性分支、许多发行分支和热传真分支以及许多繁琐的马尔吉鲁。 虽然有Git插件，但是已经没有人维护了。 由于各阶段各操作的定义非常明确，它对许多注重过程的企业来说是香馒头。 但是，那个不能简单地使用。 对大量合并冲突和整合测试不友好也是最令人诟病的地方。
是的，还有GithubFlow模式，但该战略除了基于干线的外，还添加了结合个人仓库和Pull Request代码的操作，类似于在同一仓库中添加个人分支。 从实用意义上说，它适合分布式团队。 GithubFlow还有一些改进的版本，如强调将多环境部署和仓库或分支与环境相关联的GitlabFlow模型。
是像干线基础一样简单粗暴，还是像GitFlow一样复杂？ 没有其他选择吗？
开辟新道路的AoneFlow
在AoneFlow中，可以看到许多其他分支模式的影子。 基本上，它避免了GitFlow的复杂代码部分，同时兼顾了基于干线的“易于持续集成”和GitFlow的“易于管理需求”特征。
让我们来看看具体的做法。 AoneFlow只使用三种分支类型：主干分支、特性分支、公开分支和三种基本规则。
规则一，开始工作前，从主干建立特性分支。
AoneFlow的特性分支基本上以GitFlow为参考，没有特别之处。 每次启动新的工作项目(如新功能或要解决的问题)时，都会从代表最新发布版本的主干创建一个通常使用feature/前缀命名的特性分支，并将代码修改提交到该分支。 也就是说，各工作项目可以单独进行，也可以多人合作进行。 所有修改不能直接提交给主干网。
规则2，通过整合特性分支，形成分发分支。
AoneFlow的发布分支设计非常巧妙，可以说是整个体系的精髓。 GitFlow将完成的特性分支合并到公共主线，即开发分支中，然后从公共主线引出公共分支。 类似地，基于中继的也是这样，等待在中继分支中开发所有必要的特性，然后从中继分支的特定位置引出发布分支。 AoneFlow的想法是，从主干网中引出新的分支，将这次整合或公开的所有特性分支依次整合，从而得到公开分支。 发布分支通常带有发布/前缀。
这个规则很简单，但实际的玩法相差很大
丰富了。首先，发布分支的用途可以很灵活。基础玩法是将每条发布分支与具体的环境相对应，比如release/test分支对应部署测试环境，release/prod分支对应线上正式环境等等，并与流水线工具相结合，串联各个环境上的代码质量扫描和自动化测试关卡，将产出的部署包直接发布到相应环境上。进阶点的玩法是将一个发布分支对应多个环境，比如把灰度发布和正式发布串在一起，中间加上人工验收的步骤。高级的玩法呢，要是按迭代计划来关联特性分支，创建出以迭代演进的固定发布分支，再把一系列环境都串在这个发布分支的流水线上，就有点经典持续集成流水线的味道了。再或者做一个将所有特性分支都关联在一起的发布分支，专门用于对所有提交做集成测试，就玩出了 TrunkBased 的效果。当然，这些花哨的高级玩法是我臆想的，阿里的发布分支一般都还是比较中规中矩。
其次，发布分支的特性组成是动态的，调整起来特别容易。在一些市场瞬息万变的互联网企业，以及采用“敏捷运作”的乙方企业经常会遇到这种情况，已经完成就等待上线的需求，随时可能由于市场策略调整或者甲方的一个临时决定，其中某个功能忽然要求延迟发布或者干脆不要了。再或者是某个特性在上线前发现存在严重的开发问题，需要排除。按往常的做法，这时候就要来手工“剔代码”了，将已经合并到开发分支或者主干分支的相关提交一个个剔除出去，做过的同学都知道很麻烦。在 AoneFlow 的模式下，重建发布分支只是分分钟的事，将原本的发布分支删掉，从主干拉出新的同名发布分支，再把需要保留的各特性分支合并过来就搞定。这一系列动作能够在很大程度上实现自动化，而且不会在仓库留下一堆剔除代码的记录，干净无污染。
此外，发布分支之间是松耦合的，这样就可以有多个集成环境分别进行不同的特性组合的集成测试，也能方便的管理各个特性进入到不同环境上部署的时机。松耦合并不代表没有相关性，由于测试环境、集成环境、预发布环境、灰度环境和线上正式环境等发布流程通常是顺序进行的，在流程上可以要求只有通过前一环境验证的特性，才能传递到下一个环境做部署，形成漏斗形的特性发布流。阿里有统一平台来自动化完成特性组合在发布分支间的迁移，在下面讲工具的部分里会再介绍。
规则三，发布到线上正式环境后，合并相应的发布分支到主干，在主干添加标签，同时删除该发布分支关联的特性分支。
当一条发布分支上的流水线完成了一次线上正式环境的部署，就意味着相应的功能真正的发布了，此时应该将这条发布分支合并到主干。为了避免在代码仓库里堆积大量历史上的特性分支，还应该清理掉已经上线部分特性分支。与 GitFlow 相似，主干分支上的最新版本始终与线上版本一致，如果要回溯历史版本，只需在主干分支上找到相应的版本标签即可。
除了基本规则，还有一些实际操作中不成文的技巧。比如上线后的 Hotfix，正常的处理方法应该是，创建一条新的发布分支，对应线上环境（相当于 Hotfix 分支），同时为这个分支创建临时流水线，以保障必要的发布前检查和冒烟测试能够自动执行。但其实还有一种简便方法是，将线上正式环境对应的发布分支上关联的特性分支全部清退掉，在这个发布分支上直接进行修改，改完利用现成的流水线自动发布。如果非得修一个历史版本的 Bug 怎么办呢？那就老老实实的在主干分支找到版本标签位置，然后从那个位置创建 Hotfix 分支吧，不过由于阿里的产品大多是线上 SaaS 业务，这样的场景并不多见。
正是这些简单的规则，组成了 AoneFlow 独树一帜的核心套路。
AoneFlow 中每一个看似简单的步骤都并非凭空臆造，而是经历大量产品团队反复磨砺后积累下来的经验。接下来，我会说说 AoneFlow 的技术门槛以及阿里内部的应对之道。
AoneFlow 的体验优化
谙熟武侠之道的人都懂得，掌握一个门派的看家秀丽的宝马，除了要会招式，还得有深厚的内功和趁手的兵器。否则拿了辟邪剑谱，也只能望谱兴叹。
阿里团队的内功和兵器，实际上是良好的代码习惯和齐全的配套工具。
这里说的习惯，除了开发流程和代码分支的管理方式以外，还包括日常开发中的一些约定俗成的规约。阿里的许多开发规约是有“文献”记载的，主要收录在 《阿里巴巴 Java 开发手册》 里面。它的内容现在已经公开了，所以早就不算是秘密。
举一个具体的例子。在 AoneFlow 的流程中，每次重建发布分支的时候都会重新合并然后编译代码，产生新的部署包。然而，即使代码的内容是一样的，如果工程中依赖了一些会改变的第三方软件包，依然可能导致打包出的产品行为不完全一致。因此，在阿里的代码规约中就明确地指出了，用于线上发布的代码，不可以使用包含“SNAPSHOT 版本”（即未正式发布版本）的依赖包，从而确保每次构建出的产物都是一致的。类似这样的细节还有很多，好的开发习惯是确保软件质量的必要前提。
工具可以使得团队协作更加平滑。虽然只要弄懂原理，AoneFlow 中每个分支创建、合并、更改步骤使用单纯的 Git 命令就能玩转。但其中的一些操作（比如为每个发布分支选出恰当的特性分支组合进行合并）手工执行极易出错，而且让团队的个人重复这些日常琐事的命令操作，并不是zxdbks事情。
在阿里内部，使用 AoneFlow 流程的团队基本上不用自己运行 Git 来处理分支的事情，而是由阿里巴巴集团内部名叫 Aone 的协同研发平台（以下简称平台）接管。这个承担集团 80% 产品从需求和用户故事提出到部署上线完整研发流程的平台，内置了许多以服务组件的形式嵌入的研发提效工具，其中的发布组件为 AoneFlow 的用户体验添色不少。比较显著的辅助“功效”包括以下几个方面。
首先是整体流程的自动化。
由于是内部工具，平台的功能高度内聚。对于项目而言，从提出原始需求，将需求拆分为任务，然后根据任务在线创建特性分支，再聚合生成发布分支，同时根据模板自动创建测试环境，直到后期的运维保障都可以一站式的搞定。
这个流程已经远远超出了代码分支管理的范畴。但正是因为如此，平台对于 AoneFlow，向前做到了将特性分支和需求项关联起来，确保了特性分支的命名规范性；向后做到了将发布分支与部署行为关联起来，确保了各环境版本来源的可靠性。打通了端到端交付的任督二脉。
其次是发布分支的流水线。
作为一种流程自动化的手段，CI/CD 流水线是许多现代交付团队中常见的标配实践。在 AoneFlow 的代码生命周期里涉及许多分支，当这些分支被创建或更新时，往往需要伴随其他的一系列行为。流水线能够将这些日常开发过程中的代码分支与其所表达的深层意图（比如提交代码即进行集成测试）联系起来。特别是发布分支，AoneFlow 的每个发布分支通常关联具体的部署环境，当有新代码合并进分支时，就应该及时对代码进行检查和部署。
理想情况下，每条不同的分支都应该有与其作用相匹配的一条流水线来为它服务。AoneFlow 的发布分支是相对固定的，因此相比 GitFlow 更易于进行持续集成。理论上任何流水线工具都能够配合 AoneFlow 使用，不过，阿里的统一平台提供流水线对代码评审、安全检查、在线部署等功能的整合，还是为 AoneFlow 在内部团队的使用优化增色不少。
还有一项很有用的辅助是分支关联的管理。
特性分支与发布分支的关联关系维护是一个 AoneFlow 特有的问题。记住每个发布分支分别来自哪些特性分支对于需要基于现有特性组合进行改变的时候十分有意义。比如当需要将某个特性从特定发布分支退出时，通常会将除了该特性以外的其他特性所在分支进行一次合并，以替换原有的发布分支。人为的记录这些信息并不轻松，要是通过平台进行展示和辅助就会方便许多。
当某些功能组合在一个低级别的发布环境（如集成测试环境）验证完成后，我们希望将它的内容直接迁移到高级别的环境（如预发布环境）对应的发布分支上。这样可以确保线上的版本一定是经过预发验证的，预发的版本一定是经过集成验证的，以此类推，使得各个发布分支形成串联。同样的，使用普通的 Git 命令就能实现这个操作，只不过用可视化工具会让流程更加直观。
除此以外，平台提供代码仓库各个分支状况的统一展示，包括分支所对应部署环境的机器信息、操作记录等全都一览无余。正是这些“高附加值”的辅助，使得 AoneFlow 得以扬长避短，成为阿里团队支撑复杂项目首选的利器。
不久前，2017 年 12 月 20 日云栖大会，阿里协同研发平台的团队刚刚在阿里云上 发布了一款公开版的研发效能产品：云效。相比集团内部平台，目前公开的 云效 还只是初级版本，不过值得庆幸的是，它 对 AoneFlow 的支持 已经比较完备，好奇之士可自行前往探索。
地址：https://yq.aliyun.com/articles/307586
写在最后
代码分支模式的选择并没有绝对的正确和错误之分，关键是与项目的规模和发布节奏相匹配。阿里协同研发平台在经过众多实践历练后，总结出了一套独创的分支管理方法，通过兼备灵活高效与简单实用的流程，保障阿里旗下众多产品的交付。lcdddx还在犹豫于琳琅满目的分支模式，既舍不得 GitFlow 的并行特性开发，又放不下 TrunkBased 的持续集成友好时，AoneFlow 也许是一个值得考虑的选择。
作者介绍
lhdfs（花名金戟），阿里巴巴研发效能事业部技术专家。
今日荐文
点击下方图片即可阅读
中年程序员都在想什么？
【课程推荐】深入浅出区块链——36 节课，5 大模块，上手写出你的第一个区块链项目
福利：每邀请一位好友购买，你可获得 18 元现金返现，多邀多得，上不封顶，立即提现
获取海报：关注极客时间服务号－我的－获取专属海报
提现流程：极客时间公众号 - 我的 - 现金奖励提现
订阅方式：点击下图，微信支付，立即成功订阅。