git flow

为什幺要用git flow

git flow 是一个分支管理的策略，使得版本库的演进变得简洁，主干清晰，各个分支各司其职、井井有条。

如下展示了分支混乱的场景:

hunluan.jpg

git flow是什么

git flow是一个策略，核心其实就是下图:

111.png

主分支

中心库有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