git-flow的工作流程

什么是 git-flow？

一旦安装安装 git-flow，你将会拥有一些扩展命令。这些命令会在一个预定义的顺序下自动执行多个操作。是的，这就是我们的工作流程！

git-flow 并不是要替代 Git，它仅仅是非常聪明有效地把标准的 Git 命令用脚本组合了起来。

严格来讲，你并不需要安装什么特别的东西就可以使用 git-flow 工作流程。你只需要了解，哪些工作流程是由哪些单独的任务所组成的，并且附带上正确的参数，以及在一个正确的顺序下简单执行那些对应的 Git 命令就可以了。当然，如果你使用 git-flow 脚本就会更加方便了，你就不需要把这些命令和顺序都记在脑子里。

安装 git-flow

近些年来出现了很多不同的安装方法。在本章节中我们会使用当前最流行的一种： AVH Edition。

要了解安装 git-flow 细节，请阅读下面这个文档 official documentation

分支的模式

git-flow 模式会预设两个主分支在仓库中：

master只能用来包括产品代码。你不能直接工作在这个 master 分支上，而是在其他指定的，独立的特性分支中（这方面我们会马上谈到）。不直接提交改动到 master 分支上也是很多工作流程的一个共同的规则。

develop 是你进行任何新的开发的基础分支。当你开始一个新的功能分支时，它将是_开发_的基础。另外，该分支也汇集所有已经完成的功能，并等待被整合到 master 分支中。

这两个分支被称作为 长期分支。它们会存活在项目的整个生命周期中。而其他的分支，例如针对功能的分支，针对发行的分支，仅仅只是临时存在的。它们是根据需要来创建的，当它们完成了自己的任务之后就会被删除掉。

辅助分支包括：

• feature分支：开发新功能
• release分支 ：“release/*”（*一般使用版本号）。主要是来修复bug的过程
• hotfix分支：生产环境遇到了异常情况或者发现了严重到必须立即修复的软件缺陷，创建临时分支

管理feature

开始新功能—git flow feature start rss-feed

让我们开始开发一个新功能 “rss-feed”：采用命令git flow feature start rss-feed

$ git flow feature start rss-feed
Switched to a new branch 'feature/rss-feed'

Summary of actions:
- A new branch 'feature/rss-feed' was created, based on 'develop'
- You are now on branch 'feature/rss-feed'

概念

在这些命令的输出文本中，git-flow 会对刚刚完成的操作打印出一个很有帮助的概述

当你需要帮助的时候，你可以随时请求帮助。例如：

$ git flow feature help

正如上面这个新功能一样，git-flow 会创建一个名为 “feature/rss-feed” 的分支（这个 “feature/” 前缀 是一个可配置的选项设置）。你已经知道了，在你做新功能开发时使用一个独立的分支是版本控制中最重要的规则之一。
git-flow 也会直接签出这个新的分支，这样你就可以直接进行工作了。

完成一个功能—git flow feature finish rss-feed

经过一段时间艰苦地工作和一系列的聪明提交，我们的新功能终于完成了：

$ git flow feature finish rss-feed
Switched to branch 'develop'
Updating 6bcf266..41748ad
Fast-forward
    feed.xml | 0
    1 file changed, 0 insertions(+), 0 deletions(-)
    create mode 100644 feed.xml
Deleted branch feature/rss-feed (was 41748ad).

最重要的是，这个 “feature finish” 命令会把我们的工作整合到主 “develop” 分支中去。在这里它需要等待：

一个在更广泛的 “开发” 背景下的全面测试。稍后和所有积攒在 “develop” 分支中的其它功能一起进行发布。
之后，git-flow 也会进行清理操作。它会删除这个当下已经完成的功能分支，并且换到 “develop” 分支。

管理 releases

Release 管理是版本控制处理中的另外一个非常重要的话题。让我们来看看如何利用 git-flow 创建和发布 release。

创建 release—git flow release start 1.1.5

当你认为现在在 “develop” 分支的代码已经是一个成熟的 release 版本时，这意味着：第一，它包括所有新的功能和必要的修复；第二，它已经被彻底的测试过了。如果上述两点都满足，那就是时候开始生成一个新的 release 了：

$ git flow release start 1.1.5
Switched to a new branch 'release/1.1.5'

请注意，release 分支是使用版本号命名的。这是一个明智的选择，这个命名方案还有一个很好的附带功能，那就是当我们完成了release 后，git-flow 会适当地_自动_去标记那些 release 提交。

有了一个 release 分支，再完成针对 release 版本号的最后准备工作（如果项目里的某些文件需要记录版本号），并且进行最后的编辑。

完成 release—git flow release finish 1.1.5

现在是时候按下那个危险的红色按钮来完成我们的release了：

git flow release finish 1.1.5
这个命令会完成如下一系列的操作：

首先，git-flow 会拉取远程仓库，以确保目前是最新的版本。

然后，release 的内容会被合并到 “master” 和 “develop” 两个分支中去，这样不仅产品代码为最新的版本，而且新的功能分支也将基于最新代码。

为便于识别和做历史参考，release 提交会被标记上这个 release 的名字（在我们的例子里是 “1.1.5”）。
清理操作，版本分支会被删除，并且回到 “develop”。

从 Git 的角度来看，release 版本现在已经完成。依据你的设置，对 “master” 的提交可能已经触发了你所定义的部署流程，或者你可以通过手动部署，来让你的软件产品进入你的用户手中。

hotfix

很多时候，仅仅在几个小时或几天之后，当对 release 版本作做全面测试时，可能就会发现一些小错误。
在这种情况下，git-flow 提供一个特定的 “hotfix” 工作流程（因为在这里不管使用 “功能” 分支流程，还是 “release” 分支流程都是不恰当的）。

创建 Hotfixes—$ git flow hotfix start missing-link

这个命令会创建一个名为 “hotfix/missing-link” 的分支。因为这是对产品代码进行修复，所以这个 hotfix 分支是基于 “master” 分支。

这也是和 release 分支最明显的区别，release 分支都是基于 “develop” 分支的。因为你不应该在一个还不完全稳定的开发分支上对产品代码进行地修复。

就像 release 一样，修复这个错误当然也会直接影响到项目的版本号！

完成 Hotfixes—git flow hotfix finish missing-link

在把我们的修复提交到 hotfix 分支之后，就该去完成它了：

$ git flow hotfix finish missing-link
这个过程非常类似于发布一个 release 版本：

完成的改动会被合并到 “master” 中，同样也会合并到 “develop” 分支中，这样就可以确保这个错误不会再次出现在下一个 release 中。

这个 hotfix 程序将被标记起来以便于参考。

这个 hotfix 分支将被删除，然后切换到 “develop” 分支上去。

还是和产生 release 的流程一样，现在需要编译和部署你的产品（如果这些操作不是自动被触发的话）。

常规开发

实际上我们也可以直接采用git命令完成操作,详细用法如下：

开发新功能

现在我们接到产品经理的需求，需要做一个拼团功能，按照前面描述的模型，我们首先是创建一个feature分支。

$ git checkout -b feature/group develop
现在我们将在feature/group分支上开发拼团的功能

。。。

拼团功能已经开发完成，并且已经在拼团的分支上完成了测试，具备了合并到develop分支的条件，那么拼团的团队负责人执行个合并操作，并删除功能分支。

切换到develop分支
$ git checkout develop

将feature/group合并进来
$ git merge --no-ff feature/group

删除feature分支
$ git branch -d feature/group

推送develop分支
$ git push origin develop

发布版本

功能合并到develop之后还可以继续在develop分支上进行测试和修复Bug，一切完成之后产品经理决定发布第一个版本了，版本号 1.0。这里就会用到release分支了

从develop分支上拉一个新分支
$ git checkout -b release/1.0 develop

我们可以再次在release上测试和修复bug（仅限于修复bug，严禁在release分支开发新功能）。

修复完成了，切换到master分支，将release/1.0合并进来
$ git checkout master
$ git merge --no-ff release/1.0

打上标签
$ git tag -a 1.0

如果release/1.0分支有更新则需要再次将更改合并到develop分支
$ git checkout develop
$ git merge --no-ff release/1.0

删除release/1.0分支
$ git branch -d release/1.0

紧急情况

运营反映线上版本出现了严重的问题，需要马上修复，不能等到下个版本（记住这个条件）。hotfix分支的作用就在这里。

从master分支上拉一个新分支
$ git checkout -b hotfix/1.1 master

修复完成了，切换到master分支，将hotfix/1.1合并进来
$ git checkout master
$ git merge --no-ff hotfix/1.1

打上标签
$ git tag -a 1.1

同时要合并到develop分支
$ git checkout develop
$ git git merge --no-ff hotfix/1.1

删除hotfix/1.1分支
$ git branch -d hotfix/1.1