Git 工作流

Git 的主流工作流主要分为三种工作流程：

Git 标准工作流（Git Flow）

Git Flow 中包含两个长期分支

主分支用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的发布版本

开发分支用于日常开发，存放最新的开发版本

其次，项目存在三种短期分支

一旦完成开发，这三种短期分支会被合并进开发分支或主分支中，然后被删除。

Git Flow 的优势是清晰可控，但是需要同时维护两个长期分支。

Github Flow 只有一个长期分支 —— 主分支（master）。

Github 官方推荐流程图

Github Flow 十分的简单，清晰，但是不适应于复杂的发布环境

Gitlab Flow 是对于 Git Flow 和 Github Flow 的结合，吸取了二者的优点。

Gitlab Flow 的最大原则是“上游优先（upstream first）”，只存在一个主分支，它是所有分支的“上游”。只有上游分支采纳的代码变化，才能应用到其它分支。

Gitlab Flow 能够支持持续继承和持续发布。如果你无法控制具体到发布时间，例如，IOS 应用需要等待 App Store 的检查。对于这种情况，Gitlab 建议包含两个长期分支：

功能分支和补丁分支先合并到主分支中，主分支没有问题再合并到生产分支中。

Gitlab Flow 能够支持按环境区分流程，假设项目存在两个环境 —— 预生产环境和生产环境，对于这种情况 Gitlab Flow 建议根据环境建立两个分支：

主分支（master）是预生产分支的“上游”，预生产分支又是生产分支的“上游”。

所有的开发基于主分支，开发完成后，合并进主分支。没有问题后，主分支再发布到预生产分支。预生产分支也没有问题再从预生产分支发布到生产分支

有些项目需要同时发布并维护多个版本，对于这类型的项目，Gitlab 建议每一个稳定版本都要从主分支中拉取出一个分支。例如：

假如某个版本出现了 bug，首先需要新建一个 hotfix 分支，开发完后合并进主分支，确认没有问题后再cherry-pick到出现问题的版本分支中，并且更新小版本号。

最后更新于6年前