项目版本与分支管理之阿里AoneFlow模式分析

前言

在我前期的项目管理的经验中，一个项目须要维护多个产品及多个版本，这给版本与分支的管理增长了难度。前期没有重视，使得分支太多太乱，版本也没记录好，引起了不少的问题。在多种分支与版本的管理模式下，最终参考阿里的AoneBased模式来管理分支。在此作个总结并分享给你们，但愿能够帮助你们找到适合本身项目的版本管理方式。

背景

碰到一个较复杂的自研项目，既要作原始功能的研发，还要作产品的定制化开发。前期的版本管理大体为：

• 一、共一个主干分支master
• 二、N个特性分支==N个发布分支（特性分支开发完成后，直接转测，直接转为发布分支）
• 三、不按期的更新主干分支
  产生的主要问题有
• 一、主干分支经常跟不上线上环境的代码
• 二、大量的合并突冲，集成测试不友好
• 三、版本记录混乱，功能点不明确

• 四、某功能忽然要撤回时，要手动去注销对应代码
  总之产生的问题很是多，整个项目代码管理混乱，很是不利于维护。后整理思绪，先总结一些常见的版本管理模式。

  1、TrunkBased模式

  组成

  一个主干分支 + 多个发布分支

  使用流程

  每一个发布分支在特定的提交点从主干分支中拉取出来，进行线上部署和Hotfix.

  缺点

  多个团队或多个产品在同一个主干分支上并行开发时，发布的时候就是灾难了。须要频繁的集成和足够的测试覆盖。

  小结

  TrunkBased这种模试应该是比较常见的。可是其可能是在主干分支上开发，虽能时该保持获取到最新的代码，可是很是不利于后期的维护。使用场景过于局限，适合版本维护比较单一，迭代周期比较长的的项目。好比公司官网，功能不复杂，大多都是维护下图片或动态，能够考虑这种版本管理模式。

  2、OneFlow模式

  此模式是TrunkBased的升级版，增长了Hotfix分支，采用多主干模式，通常是双主干（一个主干分支+一个主干发布分支）。OneFlow在TrunkBased模式演进中，作了一此改善，分离了主干分支和发布分支，有效的规避了一些问题。可是一样还不能知足多版本，多产品的并行开发。

  3、GitFlow模式

  组成

  一个主干分支+一个开发分支+N个特性分支+N个发布分支+N个Hotfix分支

  使用流程

  从流程图能够看出，主干分支保持了与线上环境的代码同步，但又有主发布分支隔离了未测试的不稳定代码。每次项目有新需求时，从主干分支上拉取一个最新的特性分支进行开发。开发完成时合并到发布分支上进行集成与测试，发布成功后才合到主干分支中。

  小结

  能够看出，GitFlow版本管理模式比较符合多版本的并行开发。因此它很是受一些很注重流程的公司青睐。可是，看似不错的模式在实现运用中也仍是会出现问题。好比大量的合并冲突，集成测试不友好等。那么在如此状况下，阿里的AoneFlow模式就很好的改善了这些问题，接下来看。

  4、AoneFlow模式

  组成

  一个主干分支+N个特性分支+N个发布分支

  使用流程

  
  从流程图能够看出，AoneFlow模式只有一个主干分支。每次有新需求时，从当前主干分支拉取一个特性分支。多个特性分支可同步开发，到发布时间节点时，根据不一样的环境合并不一样的分支。如测试环境发布分支，演式环境发布分支，线上环境发布分支等。成功发布后，发布分支的代码应合并到主干分支上。一样，每次合并到主干分支时要打上tag，作好记录。最后把发布分支上关联的特性分支删除。

  小结

  AoneFlow模式能够看出，对于维护不一样环境和不一样版本的状况下很是适用，也不会产生多余的分支，主干分支与线上环境保持一致。当咱们碰到有某个功能要撤销时，能够直接回滚到某次合 并记录中，去除某个发布分支，合并其他分支。利于可维护。整个流程简单有规则，轻松高效管理项目版本与分支。

总结

经过以上一系列的分析梳理，我在项目中碰到的版本管理问题获得了解决。相信你们也都能找到适合项目的管理方式。不管怎样，大小版本的记录是少不了的。想要作好一个项目的管理，让项目更好的可读可维护，咱们须要作好不少细节的工做。每个环节都寻找更优的方法。版本的管理只是其中的一部分，前路漫漫，做重而道远。欢迎各位大佬多多指点！