本节课，我来详细介绍下常见的提交工作流，并介绍如何进行选择。常见的提交工作流如下：
- 集中式工作流；
- 功能分支工作流；
- GitFlow 工作流；
- Forking 工作流。
集中式工作流
我们先来看看集中式工作流，它是最简单的一种开发方式。集中式工作流的工作模式如下图所示：
A、B、C 为 3 位开发者，每位开发者都在本地有一份远程仓库的拷贝：本地仓库。A、B、C 在本地的 master 分支开发完代码之后，将修改后的代码 commit 到远程仓库，如果有冲突就先解决本地的冲突再提交。在进行了一段时间的开发之后，远程仓库 master 分支的日志可能如下图所示：
集中式工作流是最简单的开发模式，但它的缺点也很明显：不同开发人员的提交日志混杂在一起，难以定位问题。如果同时开发多个功能，不同功能同时往 master 分支合并，代码之间也会相互影响，从而产生代码冲突。
和其他工作流相比，集中式工作流程的代码管理较混乱，容易出问题，因此适合用在团队人数少、开发不频繁、不需要同时维护多个版本的小项目中。当我们想要并行开发多个功能时，这种工作流就不适用了，这时候怎么办呢？我们接下来看功能分支工作流。
一段时间的开发之后，远程仓库 master 分支的日志如下：
功能分支工作流
功能分支工作流基于集中式工作流演进而来。在开发新功能时，基于 master 分支新建一个功能分支，在功能分支上进行开发，而不是直接在本地的 master 分支开发，开发完成之后合并到 master 分支，如下图所示：
相较于集中式工作流，这种工作流让不同功能在不同的分支进行开发，只在最后一步合并到 master 分支，不仅可以避免不同功能之间的相互影响，还可以使提交历史看起来更加简洁。
还有，在合并到 master 分支时，需要提交 PR（pull request），而不是直接将代码 merge 到 master 分支。PR 流程不仅可以把分支代码提供给团队其他开发人员进行 CR（Code Review），还可以在 PR 页面讨论代码。通过 CR ，我们可以确保合并到 master 的代码是健壮的；通过 PR 页面的讨论，可以使开发者充分参与到代码的讨论中，有助于提高代码的质量，并且提供了一个代码变更的历史回顾途径。
GitFlow 工作流
Git Flow 工作流是一个非常成熟的方案，也是非开源项目中最常用到的工作流。它定义了一个围绕项目发布的严格分支模型，通过为代码开发、发布和维护分配独立的分支来让项目的迭代流程更加顺畅，比较适合大型的项目或者迭代速度快的项目。
GitFlow 工作流中，定义了 5 种预定义的开发分支，每种开发分支都完成指定类型的代码开发，各个分支之间代码合并也遵循预定的规范。GitFlow 工作流中，定义了以下 5 种分支，分别是 master、develop、feature、release 和 hotfix。其中，master 和 develop 为常驻分支，其他为非常驻分支，不同的研发阶段会用到不同的分支。这5种分支的详细介绍见下表：
Forking 工作流
上面讲的 Git Flow 是非开源项目中最常用的，而在开源项目中，最常用到的是 Forking 工作流，例如Kubernetes、Docker 等项目用的就是这种工作流。这里，我们先来了解下 fork 操作。
fork 操作是在个人远程仓库新建一份目标远程仓库的副本，比如在GitHub 上操作时，在项目的主页点击 fork 按钮（页面右上角），即可拷贝该目标远程仓库。Forking 工作流的流程如下图所示。
假设开发者 A 拥有一个远程仓库，如果开发者 B 也想参与 A 项目的开发，B 可以 fork 一份 A 的远程仓库到自己的 GitHub 账号下。后续 B 可以在自己的项目进行开发，开发完成后，B 可以给 A 提交一个 PR。这时候 A 会收到通知，得知有新的 PR 被提交，A 会去查看 PR并 code review。如果有问题，A 会直接在 PR 页面提交评论，B 看到评论后会做进一步的修改。最后 A 通过 B 的 PR 请求，将代码合并进了 A 的仓库。这样就完成了 A 代码仓库新特性的开发。如果有其他开发者想给 A 贡献代码，也会执行相同的操作。
选择合适的提交工作流
上面我介绍了常用的 4 种提交工作流，那么该如何选择呢？其实选择也比较简单。具体选择方法如下表所示：
其实，在实际的项目开发中，集中式工作流和功能分支工作流，基本不会在正式的开发团队中被采用。项目开发中，团队内用的最多的是 GitFlow 工作流。如果你的项目还是一个开源项目，那么第三方开发者在给项目做贡献时，用的是 Forking 工作流。
另外，在标准的 GitFlow 工作流，流程过于繁琐，已经不适用当前的敏捷开发模式。业界为此，衍生出了 2 个 GitFlow 工作流变种：GitHub Flow 和 GitLab Flow。其中，GitHub Flow 因为其简单易用、功能满足性，被很多开发团队所采用。我所在的开发团队，用的都是 GitHub Flow。OneX 项目用的也是 GitHub Flow。