为什幺要用git flow
git flow 是一个分支管理的策略，使得版本库的演进变得简洁，主干清晰，各个分支各司其职、井井有条。
如下展示了分支混乱的场景:
git flow是什么
git flow是一个策略，核心其实就是下图:
主分支
中心库有2个可一直延续的分支：
- master分支
- develop分支
master分支的特点是随时可发布，这意味着前后端研发、测试和部署都已完成，需要严格控制合并执行
develop分支的特点是最新软件变更，base于master分支，为master分支提供内容。
辅助性分支
辅助分支与关键分支（master和develop）一起，用来支持团队成员们并行开发，使得易于追踪功能，协助生产发布环境准备，以及快速修复实时在线问题。与关键分支不同，这些分支总是有一个有限的生命期，因为他们最终会被移除。
分支类型包括：
- 功能分支
- 发布分支
- 热修复分支
每一种分支有一个特定目的，并且受限于严格规则，比如：可以用哪些分支作为源分支，哪些分支能作为合并目标。
功能分支
功能分支的特点如下:
- 命名方式为feature-xxx
- 通常情况下只存在本地
- 通常基于dev分支创建，开发完成后被dev分支合并，然后删除
发布分支
可以看作是master分支发布前的缓冲分支，确保发布质量。
发布分支的特点如下:
- 命名方式为release-xxx
- 版本提测后基于dev分支创建，修改完成后被dev、master分支合并，然后删除
- 允许小bugs的修改和准备发布元数据（版本号，开发时间等等），不允许新功能的叠加。
- 建议直接修改，不走pr方式
热修复分支
当线上版本出现重大问题，团队决定紧急修复尽快发布新版本，这个时候就要用到热修复分支。
特点：
- 命名方式为hotfix-xxx
- 基于master分支或者tag创建，修改完成后被dev、master分支合并，然后删除
- 建议直接修改，不走pr方式
实际操作
功能分支
创建一个功能分支
开始一项功能的开发工作时，基于develop创建分支。
$ git checkout -b feature-x develop
Switched to a new branch "feature-x"
合并一个功能到develop分支
完成的功能可以合并进develop分支，以明确加入到未来的发布：
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff feature-x
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d feature-x
Deleted branch feature-x (was 05e9557).
$ git push origin develop
--no-ff标志导致合并操作创建一个新commit对象，即使该合并操作可以fast-forward。这避免了丢失这个功能分支存在的历史信息，将该功能的所有提交组合在一起。 比较:
后一种情况，不可能从Git历史中看到哪些提交一起实现了一个功能——你必须手工阅读全部的日志信息。如果对整个功能进行回退 (比如一组提交)，后一种方式会是一种真正头痛的问题，而使用--no-ffflag的情况则很容易.
Release 分支
创建一个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(-)
完成一个release分支
master分支merge和tag
$ 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)
�删除release分支
$ git branch -d release-1.2
Deleted branch release-1.2 (was ff452fe).
热修复分支
创建修补bug分支
$ 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(-)
修复bug和修改版本号在此阶段完成
完成一个hotfix分支
首先合并到master分支，打上tag
$ 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分支已经存在，那么应该把hotfix合并到这个release分支，而不是合并到develop分支。当release分支完成后， 将bugfix分支合并回release分支也会使得bugfix被合并到develop分支。（如果在develop分支的工作急需这个bugfix，等不到release分支的完成，那你也可以把bugfix合并到develop分支
最后，删除临时分支：
$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1 (was abbe5d6).
工具
- gitflow-avh
- sourceTree
参考资料
http://nvie.com/posts/a-successful-git-branching-model/
http://www.ruanyifeng.com/blog/2012/07/git.html
