Git Flow 是什么
Git Flow是构建在Git之上的一个组织软件开发活动的模型，是在Git之上构建的一项软件开发最佳实践。Git Flow是一套使用Git进行源代码管理时的一套行为规范和简化部分Git操作的工具。
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分支。
master分支
master分支上存放的应该是随时可供在生产环境中部署的代码（Production Ready state）。当开发活动告一段落，产生了一份新的可供部署的代码时，master分支上的代码会被更新。同时，每一次更新，最好添加对应的版本号标签（TAG）。
develop分支
develop分支是保存当前最新开发成果的分支。通常这个分支上的代码也是可进行每日夜间发布的代码（Nightly build）。因此这个分支有时也可以被称作“integration branch”。
当develop分支上的代码已实现了软件需求说明书中所有的功能，通过了所有的测试后，并且代码已经足够稳定时，就可以将所有的开发成果合并回master分支了。对于master分支上的新提交的代码建议都打上一个新的版本号标签（TAG），供后续代码跟踪使用。
因此，每次将develop分支上的代码合并回master分支时，我们都可以认为一个新的可供在生产环境中部署的版本就产生了。通常而言，“仅在发布新的可供部署的代码时才更新master分支上的代码”是推荐所有人都遵守的行为准则。基于此，理论上说，每当有代码提交到master分支时，我们可以使用Git Hook触发软件自动测试以及生产环境代码的自动更新工作。这些自动化操作将有利于减少新代码发布之后的一些事务性工作。
辅助分支
辅助分支是用于组织解决特定问题的各种软件开发活动的分支。辅助分支主要用于组织软件新功能的并行开发、简化新功能开发代码的跟踪、辅助完成版本发布工作以及对生产代码的缺陷进行紧急修复工作。这些分支与主分支不同，通常只会在有限的时间范围内存在。
辅助分支包括：
- 用于开发新功能时所使用的feature分支；
- 用于辅助版本发布的release分支；
- 用于修正生产代码中的缺陷的hotfix分支。
以上这些分支都有固定的使用目的和分支操作限制。从单纯技术的角度说，这些分支与Git其他分支并没有什么区别，但通过命名，我们定义了使用这些分支的方法。
feature分支
使用规范：
- 可以从develop分支发起feature分支
- 代码必须合并回develop分支
- feature分支的命名可以使用除
master，develop，release-*，hotfix-*之外的任何名称
feature分支（有时也可以被叫做“topic分支”）通常是在开发一项新的软件功能的时候使用，这个分支上的代码变更最终合并回develop分支或者干脆被抛弃掉（例如实验性且效果不好的代码变更）。
一般而言，feature分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里。
release分支
使用规范：
- 可以从develop分支派生
- 必须合并回develop分支和master分支
- 分支命名惯例：
release-*
release分支是为发布新的产品版本而设计的。在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等等）。通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。
当develop分支上的代码已经包含了所有即将发布的版本中所计划包含的软件功能，并且已通过所有测试时，我们就可以考虑准备创建release分支了。而所有在当前即将发布的版本之外的业务需求一定要确保不能混到release分支之内（避免由此引入一些不可控的系统缺陷）。
成功的派生了release分支，并被赋予版本号之后，develop分支就可以为“下一个版本”服务了。所谓的“下一个版本”是在当前即将发布的版本之后发布的版本。版本号的命名可以依据项目定义的版本号命名规则进行。
hotfix分支
使用规范：
- 可以从master分支派生
- 必须合并回master分支和develop分支
- 分支命名惯例：
hotfix-*
除了是计划外创建的以外，hotfix分支与release分支十分相似：都可以产生一个新的可供在生产环境部署的软件版本。
当生产环境中的软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候，就需要从master分支上指定的TAG版本派生hotfix分支来组织代码的紧急修复工作。
这样做的显而易见的好处是不会打断正在进行的develop分支的开发工作，能够让团队中负责新功能开发的人与负责代码紧急修复的人并行的开展工作。
更进一步
Git Flow开发模型从源代码管理角度对通常意义上的软件开发活动进行了约束。应该说，为我们的软件开发提供了一个可供参考的管理模型。Git Flow开发模型让nvie的开发代码仓库保持整洁，让小组各个成员之间的开发相互隔离，能够有效避免处于开发状态中的代码相互影响而导致的效率低下和混乱。
所谓模型，在不同的开发团队，不同的文化，不同的项目背景情况下都有可能需要进行适当的裁剪或扩充。祝各位好运！
PS：为了简化使用Git Flow模型时Git指令的复杂性，nvie开发出了一套git增强指令集。可以运行于Windows、Linux、Unix和Mac操作系统之下。有兴趣的同学可以去看看。
首先是初始化動作：
git flow init
初始化動作會問你一些問題，大抵是命名慣例：
No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
設定完之後，預設的 branch 就變成 develop 了
1. 开发新功能
(1) 准备开发
首先要为新开发的feature取一个名字，使用命令：
git flow feature start <name>
此时本地会基于develop分支（develop分支可以认为是开发主干，下面会简称主干），创建并切换到一个新的分支feature/。
(2) 本地开发和提交
专心研发指定的功能，不要做其它事情，包括（非该feature引入的）bug fix。 有点像使用SVN时“将代码Hold在本地不提交”的状态。 但git有本地代码库，可以做提交、回退，甚至再开分支。
常用git命令：
git add <file>：添加新文件（或老文件的修改）到暂存区
git add -u：添加所有老文件的修改到暂存区
git commit：将暂存区内容做本地提交
git status：查看状态
可以本地编版本，单独提测feature。 当然，非该feature引入的BUG，要推迟到release分支打出来之后再修改。
(3) 多人协作
同一个feature的开发需要多人协作时，首先把分支推到服务器上：
git push origin feature/<name>
其他人从服务器上把分支取下来：
git fetch
git checkout feature/<name>
获取最新更新（类似SVN Update）：
git pull origin feature/<name> --rebase
# 如果出现冲突，需要手工解决并提交
将本地已提交的修改推送到服务器（类似SVN Commit）：
git push origin feature/<name>
(4) 完成开发
先确认feature分支上所有修改都已经本地提交过了。 如果有多人协作，还要确认大家都已经推到服务器，并且已经从获取了服务器的最新更新。 如果feature单独提测，要等到基本无BUG后再做此操作。
执行命令：
git flow feature finish <name>
这条命令会将feature分支上所有修改合并成一个，提交到主干。 如果没有产生冲突，则会要求填写提交日志，这个日志会在主干上永久保存，要认真写。 如果产生冲突，本地解决并提交后，重新执行上面的finish命令。 成功后，feature分支会被删除，本地位于主干。
之后更新并推送主干（即develop分支）：
git pull origin develop --rebase
git push origin develop
2. 发布主干版本
(1) 准备发布
先把准备发布的feature都finish掉，保证本地主干是最新的。 然后确定发布版本号，它会作为版本发布时的TAG名称。执行命令：
git flow release start <version>
此时本地会基于主干，创建并切换到一个新的分支release/。
多人协作方式详见上面的 1 (3)，只是 feature/ 换成 release/。
release分支上主要是bug fix，小的需求变更等，不要做大feature。 另外release分支上的每一个提交，日后都会在主干上永久保留，所以日志一定要认真写。
(2) 完成发布
当release分支测试完成后，就可以发布版本了。 确认release分支上所有修改都已经本地提交过了。 且大家都已经推到服务器，并且已经从获取了服务器的最新更新。
使用命令：
git flow release finish <version>
这条命令会在release分支当前位置打TAG，并把release分支合并到主干。 如果产生冲突，本地解决并提交后，重新执行上面的finish命令。 成功后，feature分支会被删除，本地位于主干。
之后更新并推送主干（即develop分支），详见 1（4）。
另外完成发布还会把本地master分支更新到指向最新版本，也要推送到服务器：
git push origin master
3. 发布紧急修复版本
与发布主干版本类似，参见上面的2。两点不同：
(1) 开始发布时要指定基准版本号。基于做紧急修复的命令如下：
git flow release start <version> <base>
(2) 如果不是最新发布版（即与master不重合），结束发布时不会更新master。