你应该懂 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。固然你也能够根据实际的业务场景使用本身的工做流，方式不一样，但都是为了一样的目的。