git flow开发分支管理模型

Git Flow 是什么

Git Flow是构建在Git之上的一个组织软件开发活动的模型，是在Git之上构建的一项软件开发最佳实践。Git Flow是一套使用Git进行源代码管理时的一套行为规范和简化部分Git操做的工具。

2010年5月，在一篇名为“一种成功的Git分支模型”的博文中，@nvie介绍了一种在Git之上的软件开发模型。经过利用Git建立和管理分支的能力，为每一个分支设定具备特定的含义名称，并将软件生命周期中的各种活动归并到不一样的分支上。实现了软件开发过程不一样操做的相互隔离。这种软件开发的活动模型被nwie称为“Git Flow”。

通常而言，软件开发模型有常见的瀑布模型、迭代开发模型、以及最近出现的敏捷开发模型等不一样的模型。每种模型有各自应用场景。Git Flow重点解决的是因为源代码在开发过程当中的各类冲突致使开发活动混乱的问题。所以，Git flow能够很好的于各类现有开发模型相结合使用。

在开始研究Git Flow的具体内容前，下面这张图能够看到模型的全貌（引自nvie的博文)：

Git Flow中的分支

Git Flow模型中定义了主分支和辅助分支两类分支。

一、主分支用于组织与软件开发、部署相关的活动。

主分支是全部开发活动的核心分支。全部的开发活动产生的输出物最终都会反映到主分支的代码中。

主分支分为master分支和development分支。

1). master分支

master分支上存放的应该是随时可供在生产环境中部署的代码（Production Ready state）。当开发活动告一段落，产生了一份新的可供部署的
代码时，master分支上的代码会被更新。同时，每一次更新，最好添加对应的版本号标签（TAG）。

2). develop分支

develop分支是保存当前最新开发成果的分支。一般这个分支上的代码也是可进行每日夜间发布的代码（Nightly build）。所以这个分支有时也能够被称做“integration branch”。

当develop分支上的代码已实现了软件需求说明书中全部的功能，经过了全部的测试后，而且代码已经足够稳定时，就能够将全部的开发成果合并回master分支了。对于master分支上的新提交的代码建议都打上一个新的版本号标签（TAG），供后续代码跟踪使用。

所以，每次将develop分支上的代码合并回master分支时，咱们均可以认为一个新的可供在生产环境中部署的版本就产生了。一般而言，“仅在发布新的可供部署的代码时才更新master分支上的代码”是推荐全部人都遵照的行为准则。基于此，理论上说，每当有代码提交到master分支时，咱们可使用Git Hook触发软件自动测试以及生产环境代码的自动更新工做。这些自动化操做将有利于减小新代码发布以后的一些事务性工做。

二、辅助分支组织为了解决特定的问题而进行的各类开发活动。

辅助分支是用于组织解决特定问题的各类软件开发活动的分支。

辅助分支主要用于组织软件新功能的并行开发、简化新功能开发代码的跟踪、辅助完成版本发布工做以及对生产代码的缺陷进行紧急修复工做。这些分支与主分支不一样，一般只会在有限的时间范围内存在。

辅助分支分为feature分支（开发新功能）、release分支（辅助版本发布）和hotfix分支（修正生产代码中的缺陷）。

以上这些分支都有固定的使用目的和分支操做限制。从单纯技术的角度说，这些分支与Git其余分支并无什么区别，但经过命名，咱们定义了使用这些分支的方法。

1). feature分支

通常而言，feature分支代码能够保存在开发者本身的代码库中而不强制提交到主代码库里。

使用规范：

(1).能够从develop分支发起feature分支

(2).代码必须合并回develop分支

(3).feature分支的命名可使用除master，develop，release-，hotfix-以外的任何名称

(4).feature分支（有时也能够被叫作“topic分支”）一般是在开发一项新的软件功能的时候使用，这个分支上的代码变动最终合并回develop分支或者干脆被抛弃掉（例如实验性且效果很差的代码变动）。

2). release分支

release分支是为发布新的产品版本而设计的。在这个分支上的代码容许作小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等等）。经过在release分支上进行这些工做可让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。

当develop分支上的代码已经包含了全部即将发布的版本中所计划包含的软件功能，而且已经过全部测试时，咱们就能够考虑准备建立release分支了。而全部在当前即将发布的版本以外的业务需求必定要确保不能混到release分支以内（避免由此引入一些不可控的系统缺陷）。

成功的派生了release分支，并被赋予版本号以后，develop分支就能够为“下一个版本”服务了。所谓的“下一个版本”是在当前即将发布的版本以后发布的版本。版本号的命名能够依据项目定义的版本号命名规则进行。

使用规范：

(1).能够从develop分支派生

(2).必须合并回develop分支和master分支

(3).分支命名惯例：release-*

3). hotfix分支

除了是计划外建立的之外，hotfix分支与release分支十分类似：均可以产生一个新的可供在生产环境部署的软件版本。

当生产环境中的软件遇到了异常状况或者发现了严重到必须当即修复的软件缺陷的时候，就须要从master分支上指定的TAG版本派生hotfix分支来组织代码的紧急修复工做。

这样作的显而易见的好处是不会打断正在进行的develop分支的开发工做，可以让团队中负责新功能开发的人与负责代码紧急修复的人并行的开展工做。

使用规范：

(1).能够从master分支派生

(2).必须合并回master分支和develop分支

(3).分支命名惯例：hotfix-*

Git Flow开发模型从源代码管理角度对一般意义上的软件开发活动进行了约束。应该说，为咱们的软件开发提供了一个可供参考的管理模型。Git Flow开发模型让nvie的开发代码仓库保持整洁，让小组各个成员之间的开发相互隔离，可以有效避免处于开发状态中的代码相互影响而致使的效率低下和混乱。

所谓模型，在不一样的开发团队，不一样的文化，不一样的项目背景状况下都有可能须要进行适当的裁剪或扩充。