当在团队开发中使用版本控制系统时，商定一个统一的工作流程是至关重要的。Git 的确可以在各个方面做很多事情，然而，如果在团队中还没有能形成一个特定有效的工作流程，那么混乱就将是不可避免的。

混乱的分支

疯狂的合并

基本上你可以定义一个完全适合你自己项目的工作流程，或者使用一个别人定义好的。

我们将一起学习一个当前非常流行的工作流程 git-flow。

Git-flow分支模型介绍

Gitflow工作流是经典模型，体现了工作流的经验和精髓。随着项目过程复杂化，会感受到这个工作流中深思熟虑和威力！
Gitflow工作流没有用超出功能分支工作流的概念和命令，而是为不同的分支分配一个很明确的角色，并定义分支之间如何和什么时候进行交互。

master分支

最为稳定功能比较完整的随时可发布的代码，即代码开发完成，经过测试，没有明显的bug，才能合并到master中。请注意永远不要在master分支上直接开发和提交代码，以确保master上的代码一直可用。

develop分支（Beta）

用作平时开发的主分支，并一直存在，永远是功能最新最全的分支，包含所有要发布到下一个release的代码，主要用于合并其他分支，比如 feature 分支；如果修改代码，新建 feature 分支修改完再合并到 develop 分支。所有的 feature、release 分支都是从 develop 分支上拉的。

feature分支

这个分支主要是用来开发新的功能，一旦开发完成，通过测试没问题（这个测试，测试新功能没问题），我们合并回develop 分支进入下一个 release 。

release分支

用于发布准备的专门分支。当开发进行到一定程度，或者说快到既定的发布日，可以发布时，建立一个release分支并指定版本号(可以在 finish 的时候添加)。开发人员可以对 release分支上的代码进行集中测试和修改bug。（这个测试，测试新功能与已有的功能是否有冲突，兼容性）全部完成经过测试没有问题后，将release分支上的代码合并到master分支和develop分支。

hotfix分支

用于修复线上代码的bug。从 master 分支上拉。完成 hotfix 后，打上 tag 我们合并回 master 和 develop 分支。

注意事项：

所有开发分支从 develop 分支拉取。
所有 hotfix 分支从 master 分支拉取。
所有在 master上的提交都必要要有tag，方便回滚。
只要有合并到 master 分支的操作，都需要和 develop 分支合并下，保证同步。
master 和 develop 分支是主要分支，主要分支每种类型只能有一个，派生分支每个类型可以同时存在多个。

Git-flow的安装

Mac：brew install git-flow

Centos：yum install gitflow

Windows: 参考（github.com/nvie/gitflo…

推荐工具: sourcetree

Idea插件：Git Flow Integration

Git-flow的工作方式

初始化分支

当你想把你的项目 “切换” 到 git-flow 上后，Git 还是可以像往常一样工作的。这完全是取决于你在仓库上使用特殊的 git-flow 命令或是普通的 Git 命令。换句话说，git-flow 它不会以任何一种戏剧性的方式来改变你的仓库。

git flow init

功能开发

对于一个开发人员来说，最平常的工作可能就是功能的开发。这就是为什么 git-flow 定义了很多对于功能开发的工作流程，从而来帮助你有组织地完成它。

git flow feature help

开始新的功能

git flow feature start product_3.1.3

正如上面这个新功能一样，git-flow 会创建一个名为 “feature/product_3.1.3” 的分支（这个 “feature/” 前缀是一个可配置的选项设置）。在做新功能开发时使用一个独立的分支是版本控制中最重要的规则之一。

git-flow 也会直接签出这个新的分支，这样就可以直接进行工作。

完成一个功能

git flow feature finish product_3.1.3

完成当前分支后，git flow 会进行清理操作，会将当前完成的功能分支合并到develop，并将当前的功能分支删除。

版本发布

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

git flow release help

创建release

release 分支是使用版本号命名，git flow 会自动标记这些release提交。

git flow release start 3.1.8

当前有了一个release分支，在完成针对release版本前，在当前分支做一些最后的准备工作（如pom文件的版本依赖修改，版本号修改等），并进行最后的编辑工作。

完成release

git flow release finish 3.1.8

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

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

为便于识别和做历史参考，release 提交会被标记上这个 release 的名字（在我们的例子里是 “1.1.5”）。

清理操作，版本分支会被删除，并且回到 “develop”。

从 git 的角度来看，release 版本现在已经完成。

功能修复

很多时候，仅仅在几个小时或几天之后，当对 release版本作做全面测试或者线上系统运行中，可能就会发现一些小bug。

在这种情况下，git-flow 提供一个特定的 “hotfix” 工作流程（因为在这里不管使用 “功能” 分支流程，还是 “release” 分支流程都是不恰当的）。

git flow hotfix help

创建修复

命名规则一般以最新的发布版本号添加小版本，如果当前发布版本上已有其他的修复版本，则小版本+1，如：当前线上版本为3.1.8 -> 3.1.8.1, 3.1.8.3->3.1.8.4

git flow hotfix start 3.1.8.1

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

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

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

完成修复

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

git flow hotfix finish 3.1.8.1

这个过程非常类似于发布一个 release 版本

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

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

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

Gitflow工作流程