Git 工作流程

Git 工作流程

本文介绍三种广泛使用的工作流程：

    Git flow
    Github flow
    Gitlab flow

一、Git flow

最早诞生、并得到广泛采用的一种工作流程，就是Git flow 。

它最主要的特点有两个：
（1）项目存在两个长期分支：

    主分支master
    开发分支develop

前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；后者用于日常开发，存放最新的开发版。

（2）项目存在三种短期分支：

    功能分支（feature branch）
    补丁分支（hotfix branch）
    预发分支（release branch）

一旦完成开发，它们就会被合并进develop或master，然后被删除。

二、Github flow

Github flow 是Git flow的简化版，专门配合"持续发布"。它是 Github.com 使用的工作流程。
它只有一个长期分支，就是master。

第一步：根据需求，从master拉出新分支，不区分功能分支或补丁分支。

第二步：新分支开发完成后，或者需要讨论的时候，就向master发起一个pull request（简称PR）。

第三步：Pull Request既是一个通知，让别人注意到你的请求，又是一种对话机制，大家一起评审和讨论你的代码。对话过程中，你还可以不断提交代码。

第四步：你的Pull Request被接受，合并进master，重新部署后，原来你拉出来的那个分支就被删除。（先部署再合并也可。）

三、Gitlab flow

Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。它是 Gitlab.com 推荐的做法。

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