GitFlow -- 规范的git分支管理模型

Gitflow工作流

git作为协同开发工具广泛用于业界代码管理。使用git的开源社区通过实践总结出规范的工作流（gitflow workflow）。

下面介绍两种Gitflow工作模型，简单的功能特性发布模型和更为复杂的AVH 模型。

特性发布模型

develop分支是版本迭代中集成新功能的分支，也就是CI流程全部发生在develop分支，其他功能分支（feature branch）一开始从develop分支创建，也是往develop分支合并。

可以看到每次功能分支被合并到develop分支都会产生一个新的release tag。release tag会关联一些构建产出物，如可运行二进制，安装包之类的东西。

AVH模型

这个分支管理模型就比较复杂，确实有点复杂。分支按照功能分成几种分支。

种类	命名规范	备注
master	-	用于发布稳定的版本
develop	-	用于集成开发的新功能
release	release-*	一旦develop分支集成此次迭代的所有功能，从develop新建一个分支，用于bug修改和优化
feature	feature-*	功能分支，用于开发新功能
hotfix	hotfix-*	用于主分支master上的bug修改

流程总览

图片来自：https://nvie.com/posts/a-successful-git-branching-model/

整体看着还是比较乱的，不过下面的内容全都看了之后，再回来回顾一下，可以作为一个速记图。

首先，项目新创建的时候只有master,develop分支。develop分支只能提交一些文档或者版本信息，也就是你看到的在develop上的直接提交点。要开发新功能的话，从develop分支拉一个新的功能分支，以feature-*(如feature-login)规范命名。

然后项目经理和研发负责人定此次产品迭代要添加的功能，图中你可以看到其中一个功能分支合并到develop分支后产生一个新的release。而另外一个功能分支不属于此次迭代要实现的功能，因此被放到下一个release。原则上来讲，只要此次迭代计划上线的功能在功能分支上差不多实现了，就可以合并到develop分支。随之，产生一个对应的release分支，这个release分支用于上线功能bug修改等。最后，release分支真的没问题了，合并到develop和master上去，那这次产品迭代就结束了，可以准备上线了。

那，产品线上出了问题，比如新的安全漏洞怎么办呢？

这个时候从master拉一个hotfix分支，进行临时的修补，和release分支差不多，hotfix分支也是合并到develop和master上面，递增一个小的版本号。比如此次release版本是1.0，因为这个hotfix只是一次bug修改，所以版本号可以用1.0.1.

上面把流程梳理了一遍，下面分别描述每种分支的细节。其中大部分内容来自下面两篇文章：

1. 一个 Git 分支协作模式的进化故事
2. A successful Git branching model

master & develop分支

这两个分支叫做主要分支，master分支总是可以部署的，而develop是集成新功能的分支。每次develop分支计划发版的代码成熟稳定之后，就会合并到master分支并形成一个新的release tag。

有的项目会使用git webhook写一个自动部署的脚本，每当master分支有新的提交，就会自动部署代码。

支持分支

支持分支包含三种分支，分别是hotfix,feature和release。

feature分支

从develop分支创建，最终合并到develop分支。

feature分支的主要作用是开发新的功能，在功能分支上开发完，感觉没问题，就合并到develop分支。一般情况下，功能分支都是程序员的本地分支，在origin的远程分支列表上找不到。不过，多人协作的情况下，可以在origin上创建新的功能分支。

从develop上创建新的本地功能分支：

git checkout -b myfeature develop

功能分支合并到develop分支上：

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

--no-ff的意思是禁止fast-forward，这会让git提交历史上可以看出曾经有一个功能分支出现。否则，提交历史就是直线了。

上面你可以看到fast-forward方式直接在直接在develop分支上加入了功能分支的提交点。很难辨别出哪些提交点完成某个功能。

release 分支

release 分支从develop分支创建，最终同时合并到develop分支和master分支。

release分支一般是功能分支合并到develop分支之后产生的，之后在release分支上产生的提交点一般是小的bug修改和版本元信息添加。要注意的是，这个分支只允许对现有功能修改，不允许提交新功能的实现代码。

为什么要弄一个分支出来？从develop分支拉一个release分支之后，其他的功能分支就能往develop分支上合并了，不然相互影响容易引起冲突。

创建一个release分支：

$ git checkout -b release-1.2 develop
Switched to a new branch "release-1.2"
$ ./bump-version.sh 1.2
Files modified successfully, version bumped to 1.2.
$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions(-)

创建好了之后，经过数次提交，需要合并到master和develop分支。

合并到master分支：

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2

然后合并到develop分支:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)

为什么要同时合并到master和develop分支呢？

develop分支一般不直接往master上面合，而是release分支。
合并到develop分支的原因是，后续创建的功能分支可以包含稳定的，已经发版的功能。

hotfix分支

hotfix分支从master分支创建，最终合并到develop分支和master分支上。

比如现在master上版本是1.2，然后突然间爆出一个安全漏洞。这个时候，拉一个hotfix分支修补安全漏洞。

创建一个hotfix分支：

$ git checkout -b hotfix-1.2.1 master
Switched to a new branch "hotfix-1.2.1"
$ ./bump-version.sh 1.2.1
Files modified successfully, version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)

你看到版本号新增了一个小的版本，然后修补完，提交信息合并到develop和master分支。

$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)
# 合并到master分支
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2.1
# 合并到develop分支
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)

这里需要注意的是，加入对应release分支存在，比如release-1.2存在.那不应该合并到develop分支，而应该合并到release-1.2分支。