Git-flow做者称其不适用于持续交付?

「本文已参与好文召集令活动，点击查看：后端、大前端双赛道投稿，2万元奖池等你挑战！」

前言

Git-flow是由Vincent Driessen在2010年提出的一个Git分支模型,在这10年中，Git-flow在许多软件团队中变得很是流行，以致于人们开始将其视为某种标准。
不过最近Vincent Driessen更新了他10年前那篇著名的A successful Git branching model，大意是Git-flow已不适用于当今持续交付的软件工程方式,推荐更简单的Github flow等模型

连Git-flow做者都认可Git-flow不适合持续交付了，那咱们更有必要好好研究一下了，以避免掉坑里。
本文主要包括如下内容：
1.Git-flow介绍
2.为何Git-flow不适用于持续交付？
3.Github flow介绍
4.Gitlab flow介绍

1. Git-flow是什么?

Git-flow是由Vincent Driessen在2010年提出的一个Git分支模型,其结构图以下所示，相信你们都看过

Git-flow主要包括如下分支

• master 是长期分支，通常用于管理对外发布版本，每一个commit对一个tag，也就是一个发布版本
• develop 是长期分支，通常用于做为平常开发汇总，即开发版的代码
• feature 是短时间分支，通常用于一个新功能的开发
• hotfix 是短时间分支 ，通常用于正式发布之后，出现bug，须要建立一个分支，进行bug修补。
• release 是短时间分支，通常用于发布正式版本以前（即合并到 master 分支以前），须要对预发布的版本进行测试。release 分支在经历测试以后，测试确认验收，将会被合并到 develop 和 master

1.1 Git-flow工做流程

通常工做流程以下：

• 1.平常在develop开发
• 2.若是有比较大的功能或者其余需求，那么新开分支：feature/xxx 来作，并在这个分支上进行打包和提测。
• 3.在封版日，将该版本上线的需求合并到develop，而后将开个新的分支release/版本号(如release/1.0.1),将develop合并至该分支。
• 4.灰度阶段，在releases/版本号 分支上修复BUG，打包并发布,发布完成后反合入master与develop分支
• 5.若是在全量发布后，发现有线上问题，那么在对应的master分支上新开分支hotfix/{版本号}来修复，并升级版本号，修复完成后，而后将hotfix合并到master，同时将合并到develop

2. 为何Git-flow不适用于持续交付？

在这 10 年中，Git 自己已经席卷全球，而且使用 Git 开发的最受欢迎的软件类型正在更多地转向 Web 应用程序——至少在个人过滤器气泡中。 Web 应用程序一般是持续交付的，而不是回滚的，并且您没必要支持同时 运行的多个版本的软件。

如Vincent Driessen所述。Git-flow描述了feature分支、release分支、master或develop分支以及hotfix分支是如何相互关联的。
这种方法很是适用于用户下载的打包软件，例如库和桌面应用程序。

然而，对于许多Web应用来讲，Git-flow是矫枉过正的。有时，您的develop分支和release分支之间没有足够大的差别来区分值得。或者，您的hotfix分支和feature分支的工做流程可能相同。
在这种状况下，Vincent Driessen推荐Github flow分支模型

Git-flow的主要优势在于结构清晰，每一个分支的任务划分的很清楚，而它的缺点天然就是有些复杂了
Git-flow须要同时维护两个长期分支。大多数工具都将master看成默认分支，但是开发是在develop分支进行的，这致使常常要切换分支，很是烦人。
更大问题在于，这个模式是基于"版本发布"的，目标是一段时间之后产出一个新版本。可是，不少网站项目是"持续发布"，代码一有变更，就部署一次。这时，master分支和develop分支的差异不大，不必维护两个长期分支

2.1 Git-fow什么时候值得额外的复杂性

固然，是否使用Git-flow取决于你的业务复杂性，有时使用Git-flow是必须的，主要是当你须要同时维护多版本的时候,适合的是须要『多个版本并存』的场景
所谓『多版本并存』，就是说开发团队要同时维护多个有客户使用的版本，对于传统软件，好比我开发一个新的操做系统叫作Doors，先卖v1，卖出去1000万份，而后看在v1的基础上开发v2，可是客户会持续给v1提bug，这些bug既要在v1的后续补丁中fix，也要在v2中fix，等v2再卖出去2000万份开始开发v3的时候，v1依然有客户，我就必需要维持v1、v2、v3三个多版本都要支持。

关于Git-flow同时支持多个版本，不少人可能会有疑问，由于develop只针对一个版本能持续交付
说实话我也感受挺疑问的，后面查阅资料发现还有一个衍生的support分支，能够同时支持多个版本,在兴趣的同窗可参考:mindsers.blog/post/severa…

3.Github flow介绍

Github flow它只有一个长期分支，就是master，所以用起来很是简单。

• 第一步：根据需求，从master拉出新分支，不区分功能分支或补丁分支。
• 第二步：新分支开发完成后，或者须要讨论的时候，就向master发起一个pull request（简称PR）。
• 第三步：Pull Request既是一个通知，让别人注意到你的请求，又是一种对话机制，你们一块儿评审和讨论你的代码。对话过程当中，你还能够不断提交代码
• 第四步：布署流程：当项目负责人赞成新功能能够发布，且代码也经过审核了。可是在代码合并以前仍是要进行测试。因此要把feature分支的代码部署到测试环境进行测试
• 第五步：你的Pull Request被接受，合并进master，从新部署到生产环境后，原来你拉出来的那个分支就被删除。
• 第六步：修复正式环境bug流程：从master分支切一个HotFix分支，通过以上一样的流程发起PR合并便可

3.1 Github flow的优势

Github flow的最大优势就是简单，对于"持续发布"的产品，能够说是最合适的流程。

3.2 Github flow的缺点

它的问题也在于它的假设：master分支的更新与产品的发布是一致的。也就是说，master分支的最新代码，默认就是当前的线上代码。
但是，有些时候并不是如此，代码合并进入master分支，并不表明它就能马上发布。好比，苹果商店的APP提交审核之后，等一段时间才能上架。这时，若是还有新的代码提交，master分支就会与刚发布的版本不一致。另外一个例子是，有些公司有发布窗口，只有指定时间才能发布，这也会致使线上版本落后于master分支。
上面这种状况，只有master一个主分支就不够用了。一般，你不得不在master分支之外，另外新建一个production分支跟踪线上版本。

同时对于Github flow我还有个疑问，合并到master分支后即会部署到生产环境，可是在merge后的代码难道不会产生冲突吗？合并冲突难道不须要从新测试吗？若是评论区有了解的小伙伴能够解惑下

Github flow用起来比较简单，可是在不少公司的业务开发过程当中通常都有开发、测试、预发布、生产几个环境，没有强有力的工具来支撑，我认为很难用这种简单的模式来实现管理。
看起来这种模式特别适合小团队，人少，需求少，比较容易经过这种方式管理分支。

4.Gitlab flow介绍

Gitlab flow 是 Git-flow与Github flow的综合。它吸收了二者的优势，既有适应不一样开发环境的弹性，又有单一主分支的简单和便利。它是Gitlab.com推荐的作法。
Gitlab flow的最大原则叫作”上游优先”（upsteam first），即只存在一个主分支master，它是全部其余分支的”上游”。只有上游分支采纳的代码变化，才能应用到其余分支。
Gitlab flow分为持续发布与版本发布两种状况，以适应不一样的发布类型

4.1 持续发布

对于”持续发布”的项目，它建议在master分支之外，再创建不一样的环境分支。
好比，”开发环境”的分支是master，”预发环境”的分支是pre-production，”生产环境”的分支是production。

开发分支是预发分支的"上游"，预发分支又是生产分支的"上游"。代码的变化，必须由"上游"向"下游"发展。好比，生产环境出现了bug，这时就要新建一个功能分支，先把它合并到master，确认没有问题，再cherry-pick到pre-production，这一步也没有问题，才进入production。

只有紧急状况，才容许跳过上游，直接合并到下游分支。

4.2 版本发布

对于"版本发布"的项目，建议的作法是每个稳定版本，都要从master分支拉出一个分支，好比2-3-stable、2-4-stable等等。
之后，只有修补bug，才容许将代码合并到这些分支，而且此时要更新小版本号。

4.3 Gitlab flow开发流程

对于Android开发，咱们通常使用版本发布，所以咱们使用Gitlab flow开发的工做流为

• 1.新的迭代开始，全部开发人员从主干master拉我的分支开发特性, 分支命名规范 feature-name
• 2.开发完成后，在迭代结束前，合入master分支
• 3.master分支合并后，自动cicd到dev环境
• 4.开发自测经过后，从master拉取要发布的分支，release-$version，将这个分支部署到测试环境进行测试
• 5.测出的bug，经过从release-$versio拉出分支进行修复，修复完成后，再合入release-$versio
• 6.正式发布版本，若是上线后，又有bug，根据5的方式处理
• 7.等发布版本稳定后，将release-$versio反合入主干master分支

值得注意的是，按照Github flow规范，第5步若是测出bug,应该在master上修改，而后cherry-pick到releases上来，可是这样作太麻烦了，直接在releases分支上修复bug而后再反合入master分支应该是一个简单并且能够接受的作法

总结

正如Vincent Driessen所说的,总而言之，请永远记住，灵丹妙药并不存在。考虑你本身的背景。不要讨厌。本身决定。

Git-flow适用于大团队多版本并存迭代的开发流程
Github-flow适用于中小型团队持续集成的开发流程
Gitlab-flow适用范围则介于上面两者之间，支持持续发布与版本发布两种状况

总得来讲，各类Git工做流自有其适合工做的场景,毕竟软件工程中没有银弹,读者可根据本身的项目状况对比选择使用，本身决定~

参考资料

如何看待 Git flow 发明人称其不适用于持续交付？
Git 开发工做流程：Git Flow 与 GitHub Flow
Git 工做流程
高效团队的gitlab flow最佳实践

扩展阅读

一些大厂的Git工做流，有兴趣的同窗能够了解下
在阿里，咱们如何管理代码分支？
字节研发设施下的 Git 工做流
简介个人 Git Work Flow