谙熟武侠之道的人都懂得，掌握一个门派的看家武艺，除了要会招式，还得有深厚的内功和趁手的兵器。否则拿了辟邪剑谱，也只能望谱兴叹。
阿里团队的内功和兵器，实际上是良好的代码习惯和齐全的配套工具。
这里说的习惯，除了开发流程和代码分支的管理方式以外，还包括日常开发中的一些约定俗成的规约。阿里的许多开发规约是有“文献”记载的，主要收录在 《阿里巴巴 Java 开发手册》 里面。它的内容现在已经公开了，所以早就不算是秘密。
（注：在阿里技术公众号回复“手册”，即可免费下载《阿里巴巴 Java 开发手册》）
举一个具体的例子。在 AoneFlow 的流程中，每次重建发布分支的时候都会重新合并然后编译代码，产生新的部署包。然而，即使代码的内容是一样的，如果工程中依赖了一些会改变的第三方软件包，依然可能导致打包出的产品行为不完全一致。因此，在阿里的代码规约中就明确地指出了，用于线上发布的代码，不可以使用包含“SNAPSHOT 版本”（即未正式发布版本）的依赖包，从而确保每次构建出的产物都是一致的。类似这样的细节还有很多，好的开发习惯是确保软件质量的必要前提。
工具可以使得团队协作更加平滑。虽然只要弄懂原理，AoneFlow 中每个分支创建、合并、更改步骤使用单纯的 Git 命令就能玩转。但其中的一些操作（比如为每个发布分支选出恰当的特性分支组合进行合并）手工执行极易出错，而且让团队的个人重复这些日常琐事的命令操作，并不是令人愉悦的事情。
在阿里内部，使用 AoneFlow 流程的团队基本上不用自己运行 Git 来处理分支的事情，而是由阿里巴巴集团内部名叫 Aone 的协同研发平台（以下简称平台）接管。这个承担集团 80% 产品从需求和用户故事提出到部署上线完整研发流程的平台，内置了许多以服务组件的形式嵌入的研发提效工具，其中的发布组件为 AoneFlow 的用户体验添色不少。比较显著的辅助“功效”包括以下几个方面。
首先是整体流程的自动化。
由于是内部工具，平台的功能高度内聚。对于项目而言，从提出原始需求，将需求拆分为任务，然后根据任务在线创建特性分支，再聚合生成发布分支，同时根据模板自动创建测试环境，直到后期的运维保障都可以一站式地搞定。
这个流程已经远远超出了代码分支管理的范畴。但正是因为如此，平台对于 AoneFlow，向前做到了将特性分支和需求项关联起来，确保了特性分支的命名规范性；向后做到了将发布分支与部署行为关联起来，确保了各环境版本来源的可靠性。打通了端到端交付的任督二脉。
其次是发布分支的流水线。
作为一种流程自动化的手段，CI/CD 流水线是许多现代交付团队中常见的标配实践。在 AoneFlow 的代码生命周期里涉及许多分支，当这些分支被创建或更新时，往往需要伴随其他的一系列行为。流水线能够将这些日常开发过程中的代码分支与其所表达的深层意图（比如提交代码即进行集成测试）联系起来。特别是发布分支，AoneFlow 的每个发布分支通常关联具体的部署环境，当有新代码合并进分支时，就应该及时对代码进行检查和部署。
理想情况下，每条不同的分支都应该有与其作用相匹配的一条流水线来为它服务。AoneFlow 的发布分支是相对固定的，因此相比 GitFlow 更易于进行持续集成。理论上任何流水线工具都能够配合 AoneFlow 使用，不过，阿里的统一平台提供流水线对代码评审、安全检查、在线部署等功能的整合，还是为 AoneFlow 在内部团队的使用优化增色不少。
还有一项很有用的辅助是分支关联的管理。
特性分支与发布分支的关联关系维护是一个 AoneFlow 特有的问题。记住每个发布分支分别来自哪些特性分支对于需要基于现有特性组合进行改变的时候十分有意义。比如当需要将某个特性从特定发布分支退出时，通常会将除了该特性以外的其他特性所在分支进行一次合并，以替换原有的发布分支。人为地记录这些信息并不轻松，要是通过平台进行展示和辅助就会方便许多。
当某些功能组合在一个低级别的发布环境（如集成测试环境）验证完成后，我们希望将它的内容直接迁移到高级别的环境（如预发布环境）对应的发布分支上。这样可以确保线上的版本一定是经过预发验证的，预发的版本一定是经过集成验证的，以此类推，使得各个发布分支形成串联。同样的，使用普通的 Git 命令就能实现这个操作，只不过用可视化工具会让流程更加直观。
除此以外，平台提供代码仓库各个分支状况的统一展示，包括分支所对应部署环境的机器信息、操作记录等全都一览无余。正是这些“高附加值”的辅助，使得 AoneFlow 得以扬长避短，成为阿里团队支撑复杂项目首选的利器。
