四种常见的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 工作流是一个轻型的工作流，它是GitHub 在2011年创建，其工作流遵循以下6个原则：

1. 任何时刻的master分支代码都是可以用来部署的

2. 任何新变更都需要从master派生出一个分支，并且为其起一个描述新变更内容的名字：比如 new-oauth2-scopes

3. 在本地提交该新分支变更，并且应经常性的向服务器端该同名分支推送变更

4. 当你需要帮助、反馈，或认为新分支可以合并的时候，新建一个pull request

5. 只有在其他人review通过之后，新分支才允许合并到 master 分支

6. 一旦新分支被合并推送至master分支，master分支应当立即进行部署

优势

• 该工作流对于CI/CD流程友好

• 是Git工作流的一种简版替换

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

缺陷

• 生产环境对应的代码极易处于不稳定状态

• 对于依赖发布计划的项目无法充分支持

• 该工作流并不涉及关于部署，环境，发布和问题等方面的解决方案

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

GitLab Flow

GitLab工作流由GitLab创建于2014年。这种工作流将功能驱动的开发模式与问题跟踪结合在一起。与GitHub工作流最大的不同，是GitLab工作流新创建了与环境相关的分支（比如，staging分支和production分支），适用于每次合并功能分支后不需马上部署至生产环境的项目（如SaaS软件，移动软件项目等）。

GitLab工作流遵循以下11条原则：

1. 使用功能分支进行开发，而不是直接在master分支上提交代码 （如果你的开发主分支是 master的话，下同）

2. 测试每一次commit，而不仅仅是对master分支进行测试

3. 在所有commits上运行自动化测试（如果你的测试脚本运行时间超过5分钟，就让他们并行）

4. 在合并代码之前进行code review，而不是在合并之后

5. 以分支名或者tag为准进行自动化的部署

6. tag由人来设定，而不是CI

7. 发布版本应建立在tag上

8. 已push的commits永远不要进行rebase

9. 所有人从master派生新分支，最终合并回`master

10. 修复bug时应该优先修复master分支的代码，修复之后再cherry-pick到线上分支

11. commit messages 要有意义

优势

• 相对于前两种工作流，GitLab工作流定义了如何进行CI和CD流程的整合

• 提交历史会非常清爽，历史信息看上去会更具可读性（参见：为何开发人员应该使用squash and merge, 而不是仅仅merge）

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

缺陷

• 比GitHub工作流更加复杂

• 当项目维护多生产环境版本时，将会变得和Git Flow一样复杂

One Flow

The One Flow is a proposed alternative in article GitFlow considered harmful by Adam Ruka, written in 2015. The main condition that needs to be satisfied in order to use OneFlow is that every new production release is based on the previous release. The most difference between One Flow and Git Flow that it not has develop branch.

One Flow 最初在GitFlow considered harmful by Adam Ruka, 2015这篇文章中提出，作为Git Flow的另一种选择。使用One Flow需要满足的最重要的条件，是生产版本的每一次更新都基于前一生产版本，与Git Flow最大的区别是没有develop这一分支。

优势

• 提交历史会非常清爽，历史信息看上去会更具可读性（参见：为何开发人员应该使用squash and merge, 而不是仅仅merge）

• 灵活的团队协作机制

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

缺陷

• 自动化CI/CD能力的项目慎用

• 功能分支不明确，不适用持续集成

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

参考

• “一种良好的Git分支模型” by Vincent Driessen

• “GitHub FlowGit” by Scott Chacon

• “GitFlow有害论” by Adam Ruka

• “一种良好的Git分支模型被认为是有害的” by Jussi Judin

• “GitLab Flow介绍” by GitLab

• “OneFlow — 一种Git分支模型和工作流” by Adam Ruka

• “GitLab工作流遵循的11条规则” by GitLab

翻译自：https://medium.com/@patrickporto/4-branching-workflows-for-git-30d0aaee7bf