GitLab 工作流提供了一种简单、透明和有效的 git 工作方式，并与问题跟踪系统相结合。

先上官方文档链接： GitLab Flow

使用版本控制中常见的问题是，随着时间推移，产生越来越多的分支，在那些长期维护的分支中充斥着杂乱的修改内容。

git 工作流的问题

首先来看常见的 git 工作流：

git 工作流主要的问题是：一、默认的 master 分支只是用于发布，开发都在其他分支上。二、对于多数应用来说过于复杂，特别是 release 和 hotfix 分支的不可部署导致使用上的复杂。

GitHub 工作流的问题

GitHub 工作流十分简单，只有两个分支，master 和 feature。Atlassian 公司推荐的工作流也基本类似。

GitHub 工作流的主要问题是过于简单，没有对于常见的工作场景中的问题提出解决办法。

GitLab 工作流中的生产分支（Production branch）

GitHub 工作流隐含一个假定：每次合并 feature，主分支的代码是立即发布的。然而，实际中常常不能满足这个假定，例如：你无法控制代码发布时间，例如 App 发布要等审核通过。再例如：发布时间窗口限制，合并分支的时候也许并不在发布时间窗口。

GitLab 推荐用生产分支来解决上述问题：

Gitlab flow 的最大原则叫做"上游优先"（upsteam first），即只存在一个主分支master，它是所有其他分支的"上游"。只有上游分支采纳的代码变化，才能应用到其他分支。

对于"持续发布"的项目，它建议在master分支以外，再建立不同的环境分支。比如，"开发环境"的分支是master，"预发环境"的分支是pre-production，"生产环境"的分支是production。

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

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

版本发布

对于"版本发布"的项目，建议的做法是每一个稳定版本，都要从master分支拉出一个分支，比如2-3-stable、2-4-stable等等。

以后，只有修补bug，才允许将代码合并到这些分支，并且此时要更新小版本号。

官方文档链接： GitLab Flow

参考文章
http://www.ruanyifeng.com/blog/2015/12/git-workflow.html