介绍几种Git的工作流，更好的利用Git这项工具，找到适合自己项目的工作流。

1.集中式工作流

这种工作流对于用过SVN的同学再熟悉不过了，所有同学基于 trunk 主干进行开发，开发完成将本地的代码提交到服务，如果本地有冲突的话，就先解决冲突再合入到服务器中，远程服务器就像一个集中管理者一样，如下图所示。

git_flow_center

这种就是集中式开发工作流，只在master主分支进行开发的方式。 优点是简单明了，缺点是所有开发都在上面一起提交，定位问题相对困难。

2.功能分支工作流

这种工作方式是以集中式工作流为基础，根据不同的功能拉不同的分支进行开发；这种工作流的主干分支仍然是 master 分支，但是在进行日常需求开发时不能将代码直接提交到 master 分支上，需要为特定的需求新建一个功能分支，并且取一个具有描述性的名字，例如：feat-personal-page、issue-#2000，描述性的名称可以让其他开发者快速地明白这个功能分支的主要作用，提高不同开发者之间的协同效率；功能分支功能流的提交日志记录如图所示：

git_flow_branch

如图所示，分支工作流相比集中式工作流分支历史看起来更简洁，让不同的功能开发进行隔离，避免不同功能代码相互干扰，功能开发完成需要合入主干。

3.Gitflow 工作流

可以参考最早提出这个工作流的文章：

https://nvie.com/posts/a-successful-git-branching-model/

Gitflow 工作流是目前非常成熟的一个方案，它定义了一个围绕项目发布的严格分支模型，通过为代码研发、项目发布以及维护分配独立的分支来让项目的迭代过程更加地顺畅，不同于之前的集中式工作流以及功能分支工作流，gitflow 工作流常驻的分支有两个：主干分支 master、开发分支 dev，此外针对项目研发的各个阶段，设定了特定的分支。 阶段分支常驻 master、dev 研发 feature 热修复 hotfix 发布 release 首先针对常驻分支，如图所示：

git_flow_const

常驻分支表示在项目提交历史中一直存在的分支，这里 master 分支主要跟踪项目正式发布的代码历史，dev 分支主要跟踪项目代码研发的提交历史；

此外在 master 分支上通常会为某次版本发布分配一个标签来记录版本号，这为以后项目排查定位提供便利。

接下来，我们来看 gitflow 工作流中，代码研发阶段的工作流程。

git_flow_dev

开发阶段开启某一个功能时需要从 dev 分支上新建功能分支 feature，图中所示为两个 feature 分支，代表同时有两个功能在开发中，

这里的 feature 分支使用跟功能分支工作流中的使用方式是一样的，在需求开发完成之后需要提交 PR 请求合并进 dev 分支，完成之后即可删除对应的功能分支。

很多时候，在需求研发过程中，线上的代码可能会出现BUG，这时候需要我们进行及时的修复，这就是项目迭代过程中的BUG修复阶段。

git_flow_hotfix

如上图所示，假设我们在开发的过程中线上出现了一个 bug，这时候我们需要从 master 的标签 V1.0 上检出一份分支代码 hotfix，修复并验证好了之后，

需要将 hotfix 代码分别合并到 master /dev 分支上，并在 master 的提交上打上一个标签 V2.0， 这里需要将热修复的代码分别合并进两个常驻分支是因为需要保障两边代码的一致性。

最后，我们来看下项目迭代的发布阶段，我们需要将之前开发完成的feature发布到线上去，如图:

git_flow_publish

首先在 dev 分支的提交处新建 release 分支，在这个分支上进行 bug 修复、面向发布的一些任务，这个分支不做任何功能上的任务，

完成之后将 release 分支再分别合并进 master/dev 分支，并在 master 提交上打上标签 v3.0，这样一个发布阶段的代码操作就完成了。

最后我们来看发布之后的目前的日志记录情况，

如上图所示，这里可以将没有用的分支 hotfix、release、feature 均删除了，可以看出我们的常驻分支就 master/dev，保留仍在开发的 feature。

gitflow 工作流是目前比较很成熟的方案，它的优点有：

1、发布迭代流程更顺畅 2、使得代码有了更加严谨的项目结构，方便定位排查问题

大型的项目 / 迭代速度快的推荐使用这种工作流程！

4.fork 工作流

这种主要用于开源项目，不在这里详细讨论。