你应该懂 Git Workflow：Git Flow - 好文

来来来，要上线了，把不需要上线的功能都注释掉。

这个操作让人有点不可思议。

原本我以为，程序员应该都会用 Git！可是，我发现我错了。

Git

Git 是用来做版本管理的，在使用之前，你可能需要先安装它。但通常情况下是不需要的，因为它真的太重要了，所以大部分的操作系统默认都已经安装过了。

Repository

对于 Git 仓库，有以下两种类型：

* 本地仓库，可以理解为保存在某台主机上不共享的 Git 仓库
本地仓库有太多的限制，比如说：无法远程访问、多人协作等。所以，通常情况下我们都是直接创建远程仓库的。

* 远程仓库，保存在远程服务器上的 Git 仓库
对于远程仓库，我们可以自己搭建 Git 服务器，也可以使用诸如：GitHub（收费）、GitLab、BitBucket 等现成的服务。个人比较推荐使用
GitLab。

一点思考

我想，一些程序员不使用版本管理工具（Git）来管理代码肯定是有原因的，比如说：

* 一个人开发必有必要；
* 感觉没什么用，用不用都没什么影响。
有句话好像是这样说的：“失败的原因各种各样，但成功的原因却大致相同”。我们可以思考一下下面的问题：

* 若你的代码只是保存在电脑上，要是需要在家修改代码怎么办？你不见得去哪都带着电脑吧！万一你用的电脑是台式机，那就尴尬了。
仔细想想，你可能就会觉得确实是那么回事，所以你就在 GitLab 上创建了一个私有的仓库。这是 Git 解决的第一个问题：远程协作

* 在两周的迭代后，我们发布了新的版本，却发现新的版本存在 Bug，老板要求回到上一个稳定版本。
这时候你可能就懵了，因为你已经完全不记得上一个版本是什么样子了。这是 Git 解决的第二个问题：版本控制

* 你可能会还会遇到这样的情况，团队的开发人员在 master 分支上开发的好好的，却接到客服或运营的 Bug 反馈，这时候你要改 Bug
并发布，但是新开发的功能还没开发完。
这时候，你会发现这个问题解决起来却有点麻烦，你可能就需要对大家说：“来来来，要上线了，把不需要上线的功能都注释掉”。这是 Git 要解决的第三个问题：分支管理

这里只介绍 Git 解决的三个主要问题，当然 Git 的功能远不止这些，但这三点是必须要搞明白的。

Workflow

分支管理是 Git 的强大功能，在实际的开发中能解决很多问题。而每个人对分支管理的理解是不同，也就会产生很多种分支管理方法。比如说：有的程序员只使用一个
Master 分支，开发、测试、发布、维护（Bug 修复）都在 Master 分支上完成。这样做必定会产生很多问题。

分支管理的主要目的是：满足整个研发过程中（开发、测试、发布、维护），代码的版本控制。这就需要我们在做分支管理的时候，去决策需要使用多少分支，每个分支分别需要做什么事情，以及什么时候创建/合并分支。而这些就是
Git 的工作流，是我们在整个研发过程中使用 Git 来管理代码的流程和规范。

对于 Git 工作流，常用的主要有三种，如：

* Git Flow
* GitLab Flow
* GitHub Flow
Git Flow 就是我们接下来要说明的。

Branch

首先这种工作流会用到以下几种分支：

* master，主分支，创建 Repository 时默认会生成一个 master 分支。通常情况下 master
分支是受保护的（Protected）。master 分支保存的是稳定的已发布到线上的代码，会使用 tag 来记录发布的版本。master
分支是不允许提交代码的，只能将代码合并（merge）到 master。
* develop，开发分支，从 master 创建。需要注意的是，通常情况下，我们只在 develop
上开发一些基础的代码。而对于一些新的功能，我们是不会在 develop 上开发的，因为你不能确定这些是否需要上线（或者说无法确定在哪次迭代上线）。
* feature，功能分支，从 develop 创建。feature 分支是用来开发新功能的，通常情况下新功能开发完毕后会合并的 develop。
* release，发布分支从 develop 创建。当一次迭代的功能开发并自测完成后，就可以创建发布分支。该分支通常用于测试，我们不能在该分支上完成除
Bug 修复外的其他工作。测试完成后，我们需要将 release 分支合并到 master 进行发布。发布完成后在 master 打上 tag
记录此次发布的版本，并将 hotfix 合并到 develop。
* hotfix，修复分支，从 master 创建。当我们发现线上 Bug 时，会从 master 分支上对应的 tag 处创建新的 hotfix
分支，用来修复 bug。通常情况下，紧急修复的发布相对简单，在 Bug 修复并测试完成后，可直接合并到 master 进行发布。发布完成后在 master
打上 tag 记录此次发布的版本，并将 hotfix 合并到 develop。
Workflow

对于工作流，用图来表示会更容易理解，如下图：

图中就是我们使用 Git Flow 工作时的流程。很明显，Git Flow 需要用到很多分支，这也是很多开发者放弃它的理由。对于 Git Workflow
还有其他的选择，比如：GitLab Flow 和 GitHub Flow。当然你也可以根据实际的业务场景使用自己的工作流，方式不同，但都是为了同样的目的。

热门工具换一换