版本控制工具只是提供了基础能力，实际使用起来还是有很大的灵活性。
通常来讲，团队协作的较大项目，总要有需求分支（特性分支）、主干、发布分支，它们之间应当是个什么样的关系？另外修复bug应该走什么样的流程，通过特定的分支发mr还是直接提交到主干？
结合实际软件开发模式，形成了不同的实践方案，我们称之为，工作流。
这里介绍几种常见的工作流
- Git flow
- Github flow
- Gitlab flow
Git Flow
Git Flow是最早诞生的工作流，它有master和develop两个长期分支。
master是最稳定的分支，只用来发布稳定版本。
develop分支则用来集成需求的开发。开发需求时从develop拉出feature分支，开发完后合回develop。
从develop拉出release分支，发布预览版之类的不稳定的小版本。如果有bug，在release分支上直接修复。等到版本稳定后，把release分支合回master和develop分支。
虽然release分支都是比较稳定后才合入master，但master上有时候仍会出现问题，这时候从master拉出hotfix分支进行修复，同时合入develop分支。
以上就是原始的Git Flow模型，在实际使用中还是有一些变化的。首先，develop分支也是很容易出现需求无关的bug的，这时候会从develop分支拉出bugfix分支进行修复。
其次，release分支发现的bug，现在很多实践中，往往是先修复到develop分支，再合入release分支。因为bug往往会影响进行中的需求开发，因此需要优先修复到develop。
可以看到，Git Flow其实是基于早期的软件开发模式的：软件存在稳定的大版本和不太稳定的预发布小版本，把master用作最终稳定版使用。而现代的互联网工程，更希望快速迭代，对这样的稳定分支并无诉求。
Github flow
Github flow 是一个比较简易的工作流，Github推荐的。
它只有一个长期分支，即master。需要开发需求或修bug时，从master拉出分支，改完后发起mr合回master。简单粗暴。
它的显著缺点是，假设了master的代码是直接就可以发布的，对质量很高的小型项目或许是这样，但对于一个大型项目来讲，是很难做到的。不断地有需求合入产生新的bug，master很可能是任何时候都达不到发布标准的。
当然，大型项目从master上再拉个分支用于发布也是ok的。
Gitlab flow
Gitlab flow是gitlab推荐的工作流，在Github flow的基础上补全了发布这一块的流程。
可以说Gitlab flow是跟现代CI体系集成得最深入的工作流。
对于版本发布的项目，从master拉出发布分支后，如需修复bug，应当拉bugfix分支然后发mr合入master，在通过cherry-pick合入发布分支。使得发布分支越来越稳定最终达到发布标准并在合适时机发布。
对于一些持续发布的项目，它推荐从Master拉出预发布分支和发布分支。注意，Gitlab认为，在现代CI体系下，部署应当是基于分支或标签的自动部署。即，代码合入预发布分支时，就应当自动触发CI流程最终部署到预发布环境；发布分支同理直接对应生产环境。
国内CI用得这么深的公司大概不多...无论如何，非常值得学习。
推荐阅读GitLab Flow 的 11 条规则
gitlab flow官方文档
结语
就我目前的经验而言，github flow过于简单，git flow的master在互联网时代有点累赘，gitlab flow比较贴近我心目中的最佳实践。
gitlab flow的持续集成类工作流，自动化程度很高，国内持续集成做到这个程度的公司大概不多，不过即使web项目，走它的版本发布类工作流也是很nice的。
重新总结一下它的版本发布类工作流：feature、bugfix通过mr合入master；发布前从master拉出发布分支；期间有bug先合入master再cherry-pick到发布分支。
这套工作流应用其实很广泛，国外如facebook，国内如腾讯，都有大规模使用类似的工作流。