Git Flow开发模型

TL;DR Git Flow是一种得到广泛认可的模型，通过确定分支的实际用途（master/develop/feature等），达到团队共同认知认可全部开发过程效果。

为什么需要Git开发规范（模型）

随着Git的普及，几乎所有的开发团队都在使用Git进行版本管理和团队协作。但是Git本身提供的功能很多，灵活性太大，每个人都可以有自己的使用方式和代码管理风格。

混乱的开发流程

如果整个团队没有一个共同的Git使用共识，那么合作起来需要沟通和作出妥协，沟通不畅的情况下还可能导致的问题。

轻则，分支名字千奇百怪：有的用日期，有的用功能名称，有的用Bug编号，有的用开发者自己的名字，甚至是混合体；本地分支和远程分支几十个，谁也不知道具体的分支是做什么的。

严重的情况则比如：

A向master提交了未经测试的下一个迭代或者版本才会上线的代码，并push到了服务器，这个时候线上代码出现问题需要紧急修复，B负责此事，他没有和A沟通，认为master上的代码就是线上代码，直接pull下来，修复了bug所在的代码片段，并将代码发布到了线上，这个时候A提交的未经测试的代码出现在了线上，同时由于未经过测试所以出现了很严重的Bug导致系统不可用。

这种情况在团队人员水平参差不齐或者来自不同的小组，缺乏良好沟通和合作经验的情况下，很有可能会出现。

常见的Git规范

针对这种情况，这个团队需要一个全员都认可并知晓的Git代码管理规范，这种规范最好是经过长时间工程实践考验的，通用的，容易学习和灵活的。目前工程领域里有两个开发规范或者说开发模型符合这些特征：一个是开源项目比较通用的同时也是Github官方推荐的Pull Request的方式，另一个是今天我们将要重点说明的Git Flow模型。

Git Flow简介

Git Flow模型源自Vincent Driessen在2010年发布的一篇文章: A successful Git branching model, 这边文章得到了很多人的认同（比如阮一峰的Git分支管理策略）并且在工业界得到了广泛的应用。

两个永久分支

Git Flow 模型中有两个永久存在的分支：master 和 develop

master分支

master分支上的代码永远代表着当前生产环境的代码状况，并且master分支只接受代码合并，不接受commit提交

develop分支

develop分支的代码代表这下一个迭代将要发布的代码情况，没有确定下来将要在下一个迭代发布的代码不能合并在这个分支。devlop分支的代码和master分支同步或者领先master分支，绝对不会出现落后master分支的情况。

若干辅助分支

feature分支

业务的需求等都可以看作是产品的特性，feature分支就是正在开发的多个特性构成的集合，feature分支可以同时拥有多个，具备统一的命名规范（具体命名规范在下文中详述）。feature分支起源于develop分支，最终也将合并至develop分支，但也有例外：试验性的特性如果最终证明是失败的，将被删除而不合并入develop。每一个feature代表着一个特性，这些特性只在开发完毕准备下个迭代发布时合并入develop分支，不在下一个迭代发布的特性不能合并到develop分支。

hotfix分支

线上代码出现严重Bug需要紧急修复时使用该分支。hotfix分支起源于master分支（也就是线上代码），开发完成后合并至master分支同时合并到develop分支以确保下一个版本的代码也包含这个hotfix补丁。

release分支

当develop分支代码测试完毕，准备发布时，将从develop分支发起release分支，进入release阶段的代码将不允许新特性的添加（也就是不允许feature分支合并入develop分支或者release分支），又称特性冻结（feature freeze）。release分支将进行最终最严格的测试。release分支接受为了修复bug而产生的提交。release分支持续变动，直至开发工作验收通过，这时release分支将会打上版本标签（tag）合并至master分支同时合并至devlop分支以确保develop分支是master分支的直接后继。

bugfix分支

bugfix分支和hotfix分支目的类似，但bug紧急程度不需要立即修复，而是留到下一个版本发布时修正。和hotfix不同的是bugfix起源于develop分支也最终合并于develop分支，这一点和feature分支非常相似。

support分支

如果项目有老版本的代码因为各种原因需要维护时，会需要support分支来管理这些过时但是依旧需要维护的代码。

special分支

对应于软件的各种特别版本：节日特别版（圣诞等），周年特别版等

Git Flow AVH 介绍

除了这些标准规范，作者还提供了Git的插件帮助开发者更快和更好的处理具体的细节，我们现在介绍的是比较流行的Git Flow AVH版本。

安装

这里使用Linux下安装为例子，更加详细和更多平台的安装指南请查阅官方维基git-flow AVH Edition

安装开发版本:

wget --no-check-certificate -q  https://raw.githubusercontent.com/petervanderdoes/gitflow-avh/develop/contrib/gitflow-installer.sh &amp;&amp; sudo bash gitflow-installer.sh install develop; rm gitflow-installer.sh
`</pre>

安装稳定版本:

<pre>`wget --no-check-certificate -q  https://raw.githubusercontent.com/petervanderdoes/gitflow-avh/develop/contrib/gitflow-installer.sh &amp;&amp; sudo bash gitflow-installer.sh install stable; rm gitflow-installer.sh

初始化

Git flow 通过让你回答一些分支命名规则等信息来初始化。大体问题如下：

默认的生产发布分支（production releases）的名字是什么【默认是master】
默认的develop（“next release” development）分支的名字是什么【默认是develop】
默认的feature分支的前缀是什么【默认是feature/】
默认的bugfix分支的前缀是什么【默认是bugfix/】
默认的release分支的前缀是什么【默认是release/】
默认的hotfix分支的前缀是什么【默认是hotfix/】
默认是support分支的前缀是什么【默认是support/】
默认的版本号的前缀是什么【默认是是空】
Git flow的hooks和filters的路径 [默认是git项目中的.git/hooks目录]

通过这些问题，Git flow获取了相关的配置设定，初始化完成

通用模式

Git flow的命令存在一个通用的模式，亦即 git flow MODE ACTION NAME [BASE], 下面将一一介绍：

MODE

MODE亦即模式，表示你想要使用的git flow的功能，功能负责映射命令到分支和相应的动作，常见模式有

feature
bugfix
hotfix
release

ACTION

ACTION亦即动作，表示你想要在这个模式下执行的动作，常见的动作模式有

start
finish

NAME

NAME亦即名字，表示你要完成的对象的名字，这个部分完全由你自己定义，有下面几个建议

feature / bugfix 模式下使用英文描述命名，因为这个可以方便的了解这些分支的用途
hotfix / release 模式使用版本号命名

[BASE]

按照传统惯例，[]内包裹的部分是可选的，这也不例外，base仅在start动作才有，finish动作并无此参数，base表示的是你想要操作的对象不是以默认的分支作为起点，而是以base参数指定的commit id作为起点

使用范例

开始新的feature

假设你想要开始一个新的feature，这个feature对应产品需求的“增加回复功能“，你可以使用命令如：git flow feature start add_replay_function, 该命令将会执行如下动作：

基于develop分支（或者你在初始化时指定的develop对应的分支）创建 ‘feature/add_replay_function’分支（如果你在初始化时改变了默认的feature/的分支前缀，这里也会发生相应的变动）
切换到刚刚新建的分支

在命令中feature是MODE，start是ACTION，add_replay_function是NAME

完成新的feature

当你完成一个feature的开发时，你可以使用命令：git flow feature finish add_replay_function，该命令将会执行如下操作：

将分支’feature/add_replay_function’（名字可能有所不同，见"开始新的feature"部分，下同）合并到develop分支
将本地的’feature/add_replay_function’分支删除
切换到develop分支

在命令中feature是MODE，finish是ACTION，add_replay_function是NAME

开始release

当一切准备就绪，准备开始发布新版1.0的时候，你可以使用命令如：git flow release start 1.0, 该命令将会执行如下动作：

基于 develop 分支创建 release/1.0 分支
切换至 release/1.0 分支

在命令中release是MODE，start是ACTION，1.0是NAME，注意这里的名字实际时版本号，这里推荐使用版本号

完成release

当发布完成之后，使用命令：git flow release finish 1.0, 该命令将会执行如下动作：

合并 release/1.0 到 master
master分支被打上tag
合并 release/1.0 到 develop
删除本地的 release/1.0 分支
切换至 develop 分支

中间可能会要求你填写的信息：

要求你填写 release/1.0 合并到 master 的 merge message，有默认值，可以直接使用默认值
要求你填写 tag 信息，这次提交将会被打上tag，没有默认值，建议填写本次发布的内容，改变等信息
可能会让你填写 release/1.0 合并到 develop 的 merge message，有默认值，可以直接使用默认值

通过以上的例子，你应该已经理解git flow的工作模式，剩下的命令你都可以举一反三，灵活应用，更多信息请查看官方文档。

为什么需要Git开发规范（模型）#

混乱的开发流程#

常见的Git规范#

Git Flow简介#

两个永久分支#

master分支#

develop分支#

若干辅助分支#

feature分支#

hotfix分支#

release分支#

bugfix分支#

support分支#

special分支#

Git Flow AVH 介绍#

安装#

初始化#

通用模式#

MODE#

ACTION#

NAME#

[BASE]#

使用范例#

开始新的feature#

完成新的feature#

开始release#

完成release#