这篇文章来自 gitlab 官方，原文参见：Introduction to GitLab Flow
概述
Git 的使用带来了各种分支策略和工作流程。然而，往往大多数组织最终会得到过于复杂，没有明确定义或者没有和问题跟踪系统集成的工作流程。因此，我们建议将 GitLab Flow 作为一组明确定义的最佳实践，有机的将功能驱动开发（Feature Driven Development） ，功能分支和问题跟踪结合起来。
从其他版本控制系统(如 SVN) 进入 Git 的组织经常发现很难定制出一套高效的开发流程。本文介绍的 Gitlab 流程将Git 工作流程与问题跟踪系统集成在一起。提供了一种简单，透明，有效的 Git 工作方式。
Git 提交的三个步骤
在使用 Git 作为版本控制的时候，我们首先需要学习的是 Git 提交三个步骤：将工作副本添加到暂存区域（git add）；从暂存区提交到本地仓库（git commit）；将本地的提交推送到远程仓库（git push）。而大多数的版本控制工具只有一个步骤：直接从工作副本提交到远程仓库。
Git 的分支模型
在我们刚接触 Git 没有约定好具体的分支策略之前，我们很可能将我们的存储仓库搞的一团糟。最大的问题来自于一些长期存在的分支里面都包含了部分变化的分支，导致我们很难确定哪个分支的代码是最新的，或者哪个分支的代码是可部署的。一般来说，解决这种问题的方法是采用标准化的工作模式，例如使用 Git Flow 和 GitHub Flow。在本文档里面，我们约定了一组称为 GitLab Flow 的最佳实践。
Git Flow 的问题
Git Flow 是最早使用 Git 分支的工作流程之一，受到了大量的关注。Git Flow 建议使用一个 master 分支和一个 develop 分支作为长期分支，以及支持功能，版本发布和缺陷修复的三个短期分支。开发人员工作在 develop 分支，然后合并到版本发布分支，最后合并到 master 分支。
Git Flow 的定义非常明确，但是存在两个问题：一是开发人员必须使用 develop 分支而不是 master 分支，master 默认用于保存生产代码。但是 Git 分支模型的惯例是默认在 master 上工作和在 master 上合并代码。而且大多数的工具和 IDE 都将 master 作为默认的使用分支，因此需要开发人员手动切换到 develop 分支是非常烦人的。
Git Flow 的第二个问题是：修补分支和版本发布分支带来的复杂性。这些分支对于进行以版本发布为目标的组织可能非常友好，但是对于以持续交付为目标的组织非常的不友好。持续交付为目标的组织可能根本没有建立修补分支和版本发布分支的需求。而且复杂性的增加意味着增加了开发人员犯错的几率，例如不小心将更改合并到了 master 而不是 develop。
GitHub Flow
GitHub 创建了一个更简单的方案用于执行 Git 流程。GitHub Flow 只有功能分支和 master 分支，这种流程简洁明了，得到了许多组织的采纳并取得了很大的成功。Atlassian建议采用类似的策略，尽管它们会修改功能分支。将所有内容合并到 master 分支中并经常部署意味着您可以最小化未发布的代码量，这与精益和持续交付最佳实践一致。但是，对于部署，环境，发布以及与问题的集成，此流程仍然存在许多未回答的问题。通过 GitLab Flow，我们会对这些问题做额外的回答。
上游优先原则
GitHub Flow 假定我们 master 的代码都是可以立即部署到生产上的代码，但是在大部分的情况下这是不可能的。
一是因为我们可能没办法控制版本发布的时间，比如 Apple App Store 的应用审核机制。二是当部署版本存在窗口期的时候，例如公司要求我们只能在周四晚上某个时间段部署我们最新的版本。这种情况下可以创建反映已部署代码的生产分支，然后通过合并 master 需要部署的代码到生产分支上。当我们需要查看生产中的代码的时候，可以在生产分支上查看。
