企业代码版本管理之争:TrunkBased vs GitFlow vs AoneFlow vs OneFlow vs ExeFlow

目录

• 引言
• TrunkBased
• GitFlow
• AoneFlow
• OneFlow
• ExeFlow
• 综述

引言

网络上版本管理系统之争持久而喧嚣，依照声量来说目前应该是Git占了较大的优点。不过咱们本文的关注点在于代码的分支管理模型，由于你们不管是用SVN或者Git，目的是为了解决研发过程管理中的实际问题。我这里整理几种分支管理模型，这样你们能够对照本身的痛点选择合适的模型。不过并非最灵活的方案就最好，灵活意味着分支的管理和具体研发学习曲线都更复杂。

我先根据实际生产过程当中企业面临的问题列出一个清单：

• 学习曲线（Complexity）
  企业都但愿研发团队可以快投入生产，而在版本管理这种“小事”不要花费太多精力。
• 需求变动（Release）
  企业在一个迭代过程当中是否可以彻底不进行需求的变动，不管大家的周期是两周、一个月、或者一季度。
• 线上修正（Hotfix）
  系统目前是否已经很是稳定，不存在须要发布线上修正的可能。
• 多环境（CI/CD）
  企业是否存在多环境的要求（测试、预发布、正式等）
• 长期需求（Long-Lived Version-control Story）
  企业是否存在一个大需求可能要持续数个迭代。（例如底层的基础业务模型扩展，增长新的数据隔离标识字段，涉及到系统底层或者全系统业务逻辑的变动。这里列这种需求并非说必须支持，有些普通需求因为错误的技术方案/市场的变化等状况就会变化成这样的需求，因此综合考虑边界状况。）

另外也交代一下我所在的公司背景：
咱们是一家企业内部学习培训的人力资源SAAS管理平台，对于平台改进有本身的规划和目标，可是又面临着大客户的定制化需求以及交付时间压力。技术栈仍是Java和.Net 双栈并存，因此能够说是最复杂的研发环境了。咱们也慢慢衍生出了本身的一套改进的代码版本管理模型。

TrunkBased

原理¹：研发团队在名称为 Trunk 的单一分支进行开发，当开发工做到必定阶段的时候达到可发布条件后，切出Release分支进行发布，而且Release分支是不能够修改的仅仅作发布使用。大部分SVN用户是基于本模型进行开发。
适合小团队的模型，你们都直接在Trunk上进行开发

适合较大团队的模型，你们切出短时间的特性分支进行开发，完成后合并回Trunk。

适用场景：适合于单一稳定产品线，迭代排期稳定，需求边界彻底可控的团队。
优势：模型简单
缺点：

• 线上修正：按照上图目前系统已经发布了12.1，下一个迭代也在开发中，线上发现了问题。因为Release分支是禁止修改的，而Trunk此时包含了新的特性代码没法发布，就形成了线上异常没法修复。
• 需求变动：没法支持，已经提交到Trunk的内容抽离很困难。
• 多环境：没法支持
• 长期需求：没法支持

总结：Trunk Based最大的优点就是清晰简单，付出的代价就是灵活性，基本能够说不存在任何灵活性。适用的场景我以为是进入到后期维护的大型系统，不会作太多的变动而且不会有太多的突发问题。

GitFlow

GitFlow来源应该是 Vincent Driessen 在2010年1月发表的这篇《A successful Git branching model》，基本是如今Git中最出名的流程管理方法了。

这张图相信你们都不陌生。
原理：
主要分为5个分支

• master分支存放全部正式发布的版本，能够做为项目历史版本记录分支，不直接提交代码。仅用于保持一个对应线上运行代码的 code base。
• develop分支为主开发分支，通常不直接提交代码
• feature分支为新功能分支，feature分支都是基于develop建立的，开发完成后会合并到develop分支上。同时存在多个
• release分支基于最新develop分支建立，当新功能足够发布一个新版本(或者接近新版本发布的截止日期)，从develop分支建立一个release分支做为新版本的起点，用于测试，全部的测试bug在这个分支改。测试完成后合并到master并打上版本号，同时也合并到develop，更新最新开发分支。(一旦打了release分支以后不要从develop分支上合并新的改动到release分支)，同一时间只有1个，生命周期很短，只是为了发布。
• hotfix分支基于master分支建立，对线上版本的bug进行修复，完成后直接合并到master分支和develop分支，若是当前还有新功能release分支，也同步到release分支上。同一时间只有1个，生命周期较短。
  适用场景：处于前中期的大型项目，人员较多管理场景较复杂，可是迭代相对稳定，周期内不会频繁的变动需求，尽可能不要开长需求分支。
  优势：
  可以支持线上修正、多环境
  缺点：
• 复杂度稍高
• 需求变动：不够灵活，因为主分支其实是基于develop，那意味着一旦代码提交上去，一段时间后须要撤销（本次迭代不发布）就比较困难

总结：Gitflow已经很偏向互联网风格的代码管理，考虑到了多环境、线上修正。并且如今不少IDE或者工具备整合了GitFlow的插件使用起来会更简单。对于有良好规划和进度控制的项目，应该是已经够用了。可是对于一些有交付日期的，可是需求池能够调整的项目可能还不够灵活。

AoneFlow

阿里的研发效能事业部专家基于TrunkBased和GitFlow提出了一套新思路：AoneFlow。
原理：AoneFlow 只使用三种分支类型：主干分支、特性分支、发布分支，以及三条基本规则。

1. 开始工做前，从主干建立特性分支。
   

2. 经过合并特性分支，造成发布分支。
   

3. 发布到线上正式环境后，合并相应的发布分支到主干，在主干添加标签，同时删除该发布分支关联的特性分支。
   

缺点：

• 复杂度稍高
• 多环境：因为没有develop分支因此可能测试环境构建会有一些问题。
  优势：
• 线上环境，长期需求都是支持的

总结：AoneFlow最重要的点，就是保证master分支可用和随时可发布，其余可能都是临时分支。因此取名的时候应该是Ali-One-Flow，这个含义。临时分支的组装就有不少种玩法了，须要企业根据本身的须要来定制处理。

OneFlow

OneFlow我找到两个版本，一个是国内版本，一个是国外的版本。
国内版本：
原理：此模式是TrunkBased的升级版，增长了Hotfix分支，采用多主干模式，通常是双主干（一个主干分支+一个主干发布分支）。OneFlow在TrunkBased模式演进中，作了一此改善，分离了主干分支和发布分支，有效的规避了一些问题。可是一样还不能知足多版本，多产品的并行开发。
国外版本：
原理：此模式是GitFlow的简化版本，可是（做者认为）并不比GitFlow逊色。主要也就是双分支²，除了主干分支，只会额外保持一个分支，在不一样的阶段切除特性、发布、修正分支

并且还提供了变种版本，master+develop 双主干分支的模式。

总结：国外版本的OneFlow发表在2017年，我以为他肯定了基于一个，最多两个的固定分支进行开发这种原则。提供了企业版本管理过程当中的最佳实践原则，（我以为）也启发了AoneFlow这种优秀的Flow。

ExeFlow

ExeFlow是咱们公司目前在使用的代码管理流程的名称，主要是吸收了AoneFlow的思想，同时根据咱们本身的环境进行一些流程和分支的固化。
要理解这个Flow流程，首先基于咱们的实际工做场景：
咱们的系统因为主要是面向大型企业内部使用，存在复杂的分发流程和权限控制，通过长时间的累积业务模型也很复杂各类关联和引用，因此有一些大型任务的开发周期可能会比较长，到达2-3个月的周期。
咱们的迭代周期正常是1个月。流程大概以下：

• 上月末进行迭代计划评估与安排，这里会确认下月迭代目标的Story内容与数据。各自主管进行子任务的拆分评估与排期。
• 开发时间通常是2周，咱们基本是会在月中设定研发截止线，全部研发任务要在截止线前完成提测。期间有完成的任务能够随时提测。【涉及分支：Feature，Local，Develop】
• 完整的系统集成测试时间通常是安排在第三周，测试会进行全面的测试。本周研发的主要任务一方面是处理Bug，一方面能够介入下月迭代大项的需求说明与分析。【涉及分支：Feature，Local，Develop】
• 第四周的前三天，咱们会切出预发布的分支在第四周周一时，会给出明确本次可以上线的Story List，不在清单内的都不容许合并只预发布环境（也就是咱们实际上运行需求在预发布以前仍旧有变动，只要测试人员经过了集成测试环境，就能够合并而且发布），本次发版的具体内容和通知也是当天发出。【涉及分支：Feature，Release】
• 发版通常安排在当月的最后一个周四（为了防止有线上问题，因此不能是周五次日会没有人员值守）。【涉及分支：Release，Master】

主要经历了2个大版本的变化
版本1，基本是参考GitFlow

这个版本的固定独立分支是三条：Master，Develop，Local。核心在于Release分支仍是由Develop创建，对于需求变动的支持性不够灵活。

版本2，是参考AoneFlow

（上图就是使用gitgraphjs绘制的）
这个版本的固定独立分支也仍是是三条：Master，Develop，Local。
可是核心差别在于Release分支是由Master创建，而且合并须要上线的Feature分支，而Release分支在咱们企业的流程中只会存在2-3天的时间。

总结：实际上是比较复杂的流程，并且研发的操做的内容实际更多。咱们还要锁定某些分支，设定权限管理。可是解决了咱们的问题，因此从上到下都能替换到复杂流程带来的好处。

综述

若是你完整看完了这篇文章，实际上如今须要的并非立刻选择当前企业应该选用哪种Flow管理模型，而是认真的思考企业实际面临的问题和痛点。越灵活的流程越复杂，对于研发人员初期的接收难度就越高。咱们想真正让研发团队理解并接受某个管理模型，最重要的是这个东西解决了企业面临的问题。才能让管理层、研发自身体会到好处。
我看了不少版本管理软件的对比，不管是抬Svn打Git或者反之，我以为都对也都不对。由于不管管理或者技术，自己没有对错优劣，问题是场景。若是一个简单稳定的后期维护项目，强推复杂的管理流程，效果不会好，由于没有解决任何问题，只会引入问题。
管理的核心在于解决问题，而不是管理行为自己。

---

1. 引用自Trunk Based Development Introduction↩

2. 画图工具是使用gitgraphjs↩