引言
网络上版本管理系统之争持久而喧嚣，依照声量来讲目前应该是Git占了较大的优势。不过我们本文的关注点在于代码的分支管理模型，因为大家无论是用SVN或者Git，目的是为了解决研发过程管理中的实际问题。我这里整理几种分支管理模型，这样大家可以对照自己的痛点选择合适的模型。不过并不是最灵活的方案就最好，灵活意味着分支的管理和具体研发学习曲线都更复杂。
我先根据实际生产过程中企业面临的问题列出一个清单：
- 学习曲线（Complexity）
企业都希望研发团队能够快投入生产，而在版本管理这种“小事”不要花费太多精力。 - 需求变更（Release）
企业在一个迭代过程中是否能够完全不进行需求的变更，无论你们的周期是两周、一个月、或者一季度。 - 线上修正（Hotfix）
系统目前是否已经非常稳定，不存在需要发布线上修正的可能。 - 多环境（CI/CD）
企业是否存在多环境的要求（测试、预发布、正式等） - 长期需求（Long-Lived Version-control Story）
企业是否存在一个大需求可能要持续数个迭代。（例如底层的基础业务模型扩展，增加新的数据隔离标识字段，涉及到系统底层或者全系统业务逻辑的变更。这里列这种需求并不是说必须支持，有些普通需求由于错误的技术方案/市场的变化等情况就会变化成这样的需求，所以综合考虑边界情况。）
另外也交代一下我所在的公司背景：
我们是一家企业内部学习培训的人力资源SAAS管理平台，对于平台改进有自己的规划和目标，但是又面临着大客户的定制化需求以及交付时间压力。技术栈还是Java和.Net 双栈并存，所以可以说是最复杂的研发环境了。我们也慢慢衍生出了自己的一套改进的代码版本管理模型。
TrunkBased
原理1：研发团队在名称为 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 只使用三种分支类型：主干分支、特性分支、发布分支，以及三条基本规则。
开始工作前，从主干创建特性分支。
通过合并特性分支，形成发布分支。
发布到线上正式环境后，合并相应的发布分支到主干，在主干添加标签，同时删除该发布分支关联的特性分支。
缺点：
- 复杂度稍高
- 多环境：由于没有develop分支所以可能测试环境构建会有一些问题。
优点： - 线上环境，长期需求都是支持的
总结：AoneFlow最重要的点，就是保证master分支可用和随时可发布，其他可能都是临时分支。所以取名的时候应该是Ali-One-Flow，这个含义。临时分支的组装就有很多种玩法了，需要企业根据自己的需要来定制处理。
OneFlow
OneFlow我找到两个版本，一个是国内版本，一个是国外的版本。
国内版本：
原理：此模式是TrunkBased的升级版，增加了Hotfix分支，采用多主干模式，一般是双主干（一个主干分支+一个主干发布分支）。OneFlow在TrunkBased模式演进中，做了一此改善，分离了主干分支和发布分支，有效的规避了一些问题。但是同样还不能满足多版本，多产品的并行开发。
国外版本：
原理：此模式是GitFlow的简化版本，但是（作者认为）并不比GitFlow逊色。主要也就是双分支2，除了主干分支，只会额外保持一个分支，在不同的阶段切除特性、发布、修正分支
而且还提供了变种版本，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或者反之，我觉得都对也都不对。因为无论管理或者技术，本身没有对错优劣，问题是场景。如果一个简单稳定的后期维护项目，强推复杂的管理流程，效果不会好，因为没有解决任何问题，只会引入问题。
管理的核心在于解决问题，而不是管理行为本身。