版本控制工具只是提供了基础能力，实际使用起来还是有很大的灵活性。
通常来讲，团队协作的较大项目，总要有需求分支（特性分支）、主干、发布分支，它们之间应当是个什么样的关系？另外修复 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，国内如腾讯，都有大规模使用类似的工作流。