【DevOps实践】企业应用场景众多，怎样选择合适的代码分支模型？

常见的Git类代码分支模型有Git flow、Github flow、Gitlab flow、TBD等，企业可根据其业务、团队、管控等多方因素，选用其中一种或多种代码分支模型，随着DevOps工具的引入，在不降低代码质量管控力度的同时可有效提升代码管控效率，代码分支模型的应用可更加灵活自主。

常见代码分支模型

高效的持续交付体系，必定需要一个合适的代码分支模型。分支模型有利于规范开发团队遵循统一的规则执行功能开发、问题修复、分支合并、版本迭代及发布等操作，合适的繁殖策略可以使团队合作变得平滑顺畅，项目有序向前推进。因此，企业的研发团队通常需要慎重地选择代码分支策略应用。

代码分支从大模型的原则上分为三类，一类是主干开发分支发布，一类是分支开发主干发布，还有一类是主干开发主干发布。这些原则的沉淀，一方面是由于代码管理工具的历史发展所导致，另一个方面也受业务发布的时效诉求和管理诉求所影响。

常用代码分支模型

根据开源社区网站OpenHub的统计，使用Git管理代码的项目逐年快速增加，如今Git在代码管理领域已经占据主导地位。基于Git模式的代码管理已经成为绝对主流，基于Git的常见的代码分支模型有Git flow、Github flow、Gitlab flow、TBD flow等，不同的分支模型及优缺点分别如下：

1.Git flow

Git flow是由Vincent Driessen于2010 年提出的代码分支管理模型，但是不要被名字欺骗了，git-flow并不是Git社区官方推荐的工作流。

Git flow存在两个长期的独立分支：主分支master和开发分支develop，主分支用于版本发布，主分支的每个版本都是质量稳定和功能齐全的发布版。开发分支用于日常开发工作，存放最新的开发版代码。当开发分支的代码达到稳定状态并可以发布版本时，代码需要被合并到 master 分支，然后标记上对应的版本标签（tag）。

如果需要开发新的功能或者解决代码中的问题，则创建辅助分支来解决问题，辅助分支常用于：功能开发（Feature），版本发布（Release），问题修复（Hotfix）等，在辅助分支上的工作完成后，辅助分支将被删除。

优点：在于流程清晰，分支管理严格，适用于发布周期比较长的“版本发布”，发布周期可能是几周，几个月，甚至更长时间。

缺点：由于保持两个长期分支同步的开销较大，所以Git flow并不适用于快速的“持续发布”。

2.GitHub flow

GitHub flow是由Scott Chacon于2011年提出的代码分支管理模型，这是GitHub官方推荐的开发流程，以快速部署为目标，目前大部分开源项目都遵循这一流程。 Github flow最大的特点是只有一个长期分支，即主分支master，且主分支始终保持可发布状态。从master上创建新分支进行功能开发、问题修复等，这些分支通过pull request将代码合并到master。

为了保证主分支的代码质量，master的权限只开放给一部分人。Pull request是请求别人pull你的代码库（repository），也就是把开发分支的代码经过代码评审并通过测试后，让有权限的管理员合并回master。

不过在实际情况中，代码评审不可能检查出提交的代码中的所有问题，所以对于每次提交的代码进行自动化测试，主分支代码的自动化部署尤其重要，自动化测试能在产品部署前及时发现一部分问题，如果产品部署之后发现严重问题，自动化部署可以在最短时间内把产品回滚到上一个版本。

优点：在于流程简单灵活，不需要考虑及管理太多的分支，适用于需要快速集成及“持续发布”的项目，这类项目可能需要每天发布一个版本，甚至一天发布多个版本。

缺点：对于应用场景比较复杂的情况，例如：多个环境下的产品部署，多个版本的发布或问题修复，只有一个master便会显得力不从心。

3.Gitlab flow

GitLab flow是由GitLab 的 CEO Sytse Sijbrandij 于 2014 年正式发布的代码分支管理模型，属于GitHub flow的演进版本，与GitHub相同之处是也存在一个长期主分支mater，从master上创建新分支进行功能开发、问题修复等，结束后合并回master。

与GitHub不同之处是GitLab flow又考虑多环境部署等现实因素，增加production产品分支用于在不同的环境下部署产品，或者从master的稳定版本创建release发布分支用于发布软件。 如果在产品分支或者发布分支发现问题，就从对应版本分支创建修复分支，修复完成之后，GitLab flow遵循 “上游优先” 的合并策略，也就是将代码先合并到 master，再合并到下游的production或release分支。

和Github flow类似，master的修改权限只开放给部分人，开发分支的工作完成后，代码通过merge request（类似于GitHub flow中的pull request）请求有权限的管理员把代码合并（merge）回主分支。

4.TBD flow

TBD (Trunk-based Development) flow是由Paul Hammant于2013年提出的模型, TBD flow最大的特点是所有开发都基于主干trunk，不再有长期的开发分支，要求所有的提交尽快回到主干，这样可以共享最新的代码，并且能尽可能地减少合并冲突。如果需要发布版本，可以基于trunk直接生成新的分支用于发布。

TBD flow没有pull或者push request，要求开发人员尽快把代码提交到主干分支，但是TBD flow缺乏严格的流程来保证每一份提交代码的质量，如果一些项目开发人员众多且水平不一，同时工作在主分支上可能会在产品发布时才发现不可预知的问题，所以TBD flow更适用于需要快速迭代的产品，如果在主干分支上发现问题，可以快速进行修复再合并回主干分支。

分支模型应用分析

企业中，由于业务场景的不同，不同团队对于代码分支模型的应用也会有所不同，通常来说，会由对代码管控的强/弱程度、应用发布的高低频率为主要考虑因素来决定团队的代码分支模型。

场景1：强管控、低发布

该类型的开发常见于大型项目或者传统瀑布模式。比如，在众多大型企业中仍在执行的按季发布的方式。这一类型的场景，对于源代码的提交、源代码合并往往需要执行严格的人工Code Review，从而会有明显的多分支特征。基于该类场景，可采用Git flow的分支模型，有利于实现对源代码的强管控。

场景2：强管控、高发布

该类型的开发常见于直接面向客户的互联网项目，比如互联网金融、移动App等，由于业务的重要性，需要进行源代码更新的强管控，同时，又由于业务具有互联网属性，所以，需要经常性的发布。该场景下可选用Gitlab flow，既可以满足高频发布，又可以实现针对任一历史版本的修复。

场景3：弱管控、高发布

该类型的开发也常见于直接面向客户的互联网项目，和场景2的业务所不同的是，该场景下的业务的重要性较弱，比如一些娱乐性的产品。

该场景的弱管控是指减少人工code review，取而代之的是采用源代码扫描工具进行检测，以工具检测自动化在代码提交前完成相关质量检测。基于该前提，可采用Github flow、Gitlab flow、TBD等分支模型，尤其是在团队成熟度高的情况下，可优先考虑TBD模型，将发布频率提升至极限。

场景4：弱管控、低发布

该类场景为理论场景，如现实工作中存在该场景，可采用Git flow模型。

总结

在选择分支模型中，除了业务要求对代码管控的强弱以及业务的发布频率外，往往还会遇到业务需求是否要发布、团队成熟度、研发过程自动化工具支撑程度等问题影响。

随着DevOps在企业中的普及，以产品化为思路的持续交付模型在各企业内先后建立，借助DevOps平台自动化的能力，企业可将提交检测、合并检测等工作常态化，用自动化的代码检测方式替代人工Code review，降低人工成本的同时，提升交付效率。

同时，企业可根据自身的业务特征基于上述代码分支模型，规约企业特有的分支模型，其核心思想是在满足业务、管理、效率、质量、安全的多方诉求。