四种常见的Git工作流

在这篇文章中，我们将会讨论最受Git用户欢迎的几种分支工作流程，您可以选择最适合自己的方式。

Git Flow

Git工作流是最广为人知的工作流。由Vincent Driessen 在2010年所发明，这种工作流建立在两个具有永久生命周期的分支基础之上：

master分支 - 对应生产环境的线上代码。所有开发代码都会在某个时间点合并到master分支。

develop分支 - 对应的是预生产的代码。当功能分支开发完毕之后，会被合并到develop分支。

与之并行的，是在开发周期之内，还会使用一些其他类型的分支以便支持开发流程：

feature-* ( * 表示通配符，下同) 分支 — 功能分支用来开发下次发布包含的新功能。这些分支应当都是从develop分支派生出来，然后最终也应该合并回develop分支。

hotfix-* 分支 — 当master分支中含有不应出现的状况时，则有必要派生出hotfix分支对master分支进行紧急修复。这些分支应当派生自master 分支，并且最终应当同时合并回master 和develop 分支。

release-* 分支 — release 分支用于准备一次新的生产环境版本更新。创建release-*分支用来修复一些在测试环境未发现的小BUG，以及更新此版本的原信息。其应当派生自develop分支，并且最终同时合并回master 分支和 develop分支。

优势

在项目周期之内，该工作流保证任何时刻两个主要分支都是处于纯净状态的

由于遵循系统化的模式，因此分支命名容易理解

大多数Git工具都支持该工作流的扩展工具

当项目中需要同时维护多个生产版本时，该工作流模式非常理想

缺陷

Git 的历史记录将变得异常混乱，可读性很差

master / develop 分支的割裂使CI/CD流程变得更加困难

当项目维护单一生产环境版本时，该工作流则不适用

GitHub Flow

GitHub 工作流是一个轻型的工作流，它是