GitFlow实战

什么是GitFlow

GitFlow是Git的一种分支模式。因为能够非常好的适应团队开发，正在变得越来越流行。
这个模式来源于Vincent Driessen的一篇文章GitFlow

优点

1. 并行开发
2. 团队合作
3. 阶段式发布
4. 应急处理

工作流程

是时候贴出这张著名的图片了:)

GitFlow

来仔细地看看这张图里的内容。

1. 刚开始的时候有一个origin/master分支，tag为0.1。master是发布的主分支。其HEAD总是指向准备发布的代码。tag可以视作版本。
2. 刚开始的时候有一个origin/develop分支。develop分支是开发的主分支。其HEAD总是指向下一次准备发布的最新代码。也有人将develop分支称之为集成分支，因为集成测试基本都上根据这个分支的最新代码来做。
3. 现在需要开发新的功能，所以从develop分支拉出了一个feature分支.

git checkout -b feature/feature1 develop

4. 在这个新功能开发完后，代码需要合并到develop上

git checkout develop
git merge --no-ff feature/feature1

5. 有些新功能没有开发完，或者这次上线不需要，暂时不merge到develop中。
6. 要上线的功能都已经基本开发完成，需要测试，部署。这个时候从develop最新版本中拉出一个release分支

git checkout develop
git pull
git checkout -b release/v0.2 develop

7. 在测试的过程中发现了bug，或者可能有些功能还没有开发（个人感觉没有开发完的功能也可以看成是一个bug⊙ . ⊙），需要修复。这个时候需要从最新的release分支中拉出新的feature分支。

git checkout -b feature/fix_bug release/v0.2

在解决问题后，分别merge到develop和release分支。

git checkout develop
git merge --no-ff feature/fix_bug
git checkout release/v0.2
git merge --no-ff feature/fix_bug

可以看到feature分支可能从develop拉出来，但是最后必须merge到develop分支。

8. 经过一系列的测试之后，终于决定发布新版本了。这个时候将最新的release分支merge到master分支，并打出最新的tag。

git checkout master
git merge --no-ff release/v0.2
git tag -a 0.2

9. 在上线之后，如果发现了一个bug需要修复，这时从master分支中拉出一个hotfix分支。

git checkout master
git checkout -b hotfix/fix_bug2 master

在解决掉问题后，将该hotfix分支分别merge到develop分支和master分支，并打出新的tag

git checkout master
git merge --no-ff hotfix/fix_bug2
git tag -a 0.2.1
git checkout develop
git merge --no-ff hotfix/fix_bug2

后面再出现bug也按照同样的流程处理。

10. 回到develop分支重复上面的流程。

整个GitFLow的大致流程大概就是这样。
在工作中采用这套流程一段时间后，个人体会，这是一套非常科学，规范的流程。严格遵守流程进行项目的开发，可以在项目管理上省下不少心思。

至于在操作中可能出现的冲突等问题，已经不是GitFlow需要解决的问题，更多应该去看官方文档。