前言

在我前期的项目管理的经验中，一个项目需要维护多个产品及多个版本，这给版本与分支的管理增加了难度。前期没有重视，使得分支太多太乱，版本也没记录好，引发了很多的问题。在多种分支与版本的管理模式下，最终参考阿里的AoneBased模式来管理分支。在此做个总结并分享给大家，希望可以帮助大家找到适合自己项目的版本管理方式。

背景

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

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

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

  一、TrunkBased模式

  组成

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

  使用流程

  

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

  缺点

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

  小结

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

  二、OneFlow模式

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

  三、GitFlow模式

  组成

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

  使用流程

  

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

小结

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

四、AoneFlow模式

组成

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

使用流程

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

小结

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

总结

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