GitFlow工作流

Git Flow 常用的分支

1.Production 分支

也就是我们经常使用的Master分支，这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改

2.Develop 分支

这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支

3.Feature 分支

这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release

4.Release分支

当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支

5.Hotfix分支

当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release

Git Flow 流程演进

1.初始分支 用于记录历史的分支

Gitflow使用两个分支来记录项目开发的历史，而不是使用单一的master分支。在Gitflow流程中，master只是用于保存官方的发布历史，而develop分支才是用于集成各种功能开发的分支。使用版本号为master上的所有提交打标签（tag）也很方便。
所有在Master分支上的Commit应该Tag。

2.Feature 分支 用于功能开发的分支

每一个新功能的开发都应该各自使用独立的分支。为了备份或便于团队之间的合作，这种分支也可以被推送到*仓库。但是，在创建新的功能开发分支时，父分支应该选择develop（而不是master）。当功能开发完成时，改动的代码应该被合并（merge）到develop分支。功能开发永远不应该直接牵扯到master。
分支名 feature/*
Feature分支做完后，必须合并回Develop分支, 合并完分支后一般会删点这个Feature分支，但是我们也可以保留。

3.Release分支 用于发布的分支

一旦develop分支积聚了足够多的新功能（或者预定的发布日期临近了），你可以基于develop分支建立一个用于产品发布的分支。这个分支的创建意味着一个发布周期的开始，也意味着本次发布不会再增加新的功能——在这个分支上只能修复bug，做一些文档工作或者跟发布相关的任务。在一切准备就绪的时候，这个分支会被合并入master，并且用版本号打上标签。另外，发布分支上的改动还应该合并入develop分支——在发布周期内，develop分支仍然在被使用（一些开发者会把其他功能集成到develop分支）。
使用专门的一个分支来为发布做准备的好处是，在一个团队忙于当前的发布的同时，另一个团队可以继续为接下来的一次发布开发新功能。这也有助于清晰表明开发的状态，比如说，团队在汇报状态时可以轻松使用这样的措辞，“这星期我们要为发布4.0版本做准备。”从代码仓库的结构上也能直接反映出来。常用的一些措辞还有：基于develop新建分支，合并入master。
分支名 release/*
Release分支基于Develop分支创建，打完Release分之后，我们可以在这个Release分支上测试，修改Bug等。同时，其它开发人员可以基于开发新的Feature (记住：一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)
发布Release分支时，合并Release到Master和Develop， 同时在Master分支上打个Tag记住Release版本号，然后可以删除Release分支了。

4.维护分支 Hotfix 用于维护的分支

发布后的维护工作或者紧急问题的快速修复也需要使用一个独立的分支。这是唯一一种可以直接基于master创建的分支。一旦问题被修复了，所做的改动应该被合并入master和develop分支（或者用于当前发布的分支）。在这之后，master上还要使用更新的版本号打好标签。
这种为解决紧急问题专设的绿色通道，让团队不必打乱当前的工作流程，也不必等待下一次的产品发布周期。你可以把用于维护的分支看成是依附于master的一种特别的发布分支。
分支名 hotfix/*
hotfix分支基于Master分支创建，开发完后需要合并回Master和Develop分支，同时在Master上打一个tag

Git Flow 代码演示（这里只是展示代码流程，下面有更简便的方法）

1.创建develop分支

//创建develop分支
git branch develop
//推送develop分支到远程仓库
git push -u origin develop

2.开始新Feature开发

//切换并复制develop分支到feature分支
git checkout -b some-feature develop
//Optionally, push branch to origin:
git push -u origin some-feature    
//做一些改动
git status
git add some-file
git commit

3.完成Feature

//拉取远程develop分支的代码
git pull origin develop
//切换到本地develop分支
git checkout develop
//develop分支合并feature分支
git merge --no-ff some-feature
//推送到远程develop分支
git push origin develop
//删除本地分支
git branch -d some-feature
//删除远程分支
git push origin --delete some-feature 

4.开始Relase

//复制develop分支代码到release分支
git checkout -b release-0.1.0 develop

5.完成Release

//切换到develop分支
git checkout develop
//合并release分支代码到develop分支
git merge --no-ff release-0.1.0
//推送到远程develop仓库
git push
//切换到master分支
git checkout master
//release分支代码合并到master分支
git merge --no-ff release-0.1.0
//推送到远程master仓库
git push
//删除本地release分支
git branch -d release-0.1.0
//删除远程release分支
git push origin --delete release-0.1.0   
//给当前分支打标签
git tag -a v0.1.0-master
//将本地所有标签一次性提交
git push  --tags

6.开始Hotfix

//切换到hotfix分支
git checkout -b hotfix-0.1.1 master 

7.完成Hotfix

//切换到develop分支
git checkout develop
//合并hotfix分支代码到develop分支
git merge --no-ff hotfix-0.1.1
//推送到远程develop仓库
git push
//切换到master分支
git checkout master
//合并hotfix分支代码到master分支
git merge --no-ff hotfix-0.1.1
//推送到远程master仓库
git push
//删除本地hotfix分支
git branch -d hotfix-0.1.1
//给当前分支打标签
git tag -a v0.1.1-master
//将本地所有标签一次性提交
git push —tags

Git Flow 实例（安装gitflow插件傻瓜式操作）推荐！！

发布版本：

git flow (feature/release) publish 分支名

安装gitflow：

$ git clone --recursive git://github.com/nvie/gitflow.git
$ cd gitflow/
$ sudo make install
$ ls /usr/local/bin/git-flow
/usr/local/bin/git-flow

到项目根目录下执行gitflow，因为之前修改没有commit，所以gitflow初始化失败：

$ git flow init
fatal: Working tree contains unstaged changes. Aborting.

commit后再次进行gitflow初始化：

$ git commit -a -m "update Bash"
[master 8f5b874] update Bash
 4 files changed, 71 insertions(+), 5 deletions(-)
[[e-mail] zhuji]$ git flow init
Which branch should be used for bringing forth production > releases?
   - master
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? [] 

一路回车下来，各个分支名都按默认的设置。最后，当前分支已经被切换到了develop：

$ git branch
* develop
  master

建立一个新的feature。git flow新建了功能分支feature/blog_builder，并在develop的基础上checkout了新分支：

$ git flow feature start blog_builder
$ git branch
  develop
* feature/blog_builder
  master

开发完成后执行如下命令：

$ git flow feature finish blog_builder
Summary of actions:
- The feature branch 'feature/blog_builder' was merged into 'develop'
- Feature branch 'feature/blog_builder' has been removed
- You are now on branch 'develop'

正如这条命令的总结所言，git flow为我们做了3件事：

把feature/blog_builder合并到了develop。
删除了feature/blog_builder分支。
切换回develop分支。

接下来发布一个正常的版本：

$ git flow release start v0.5

一旦需要发布的版本确认无误可以发布后，执行命令：

$ git flow release finish v0.5
summary of actions:
- Latest objects have been fetched from 'origin'
- Release branch has been merged into 'master'
- The release was tagged 'v0.5'
- Release branch has been back-merged into 'develop'
- Release branch 'release/v0.5' has been deleted

注意release/v0.5被合并到了master和develop分支，并打了个v0.5的tag，然后被删除，最后切换回了develop分支：

$ git branch
* develop
  master

发布时只需将tag为v0.5的版本checkout出来部署即可：

$ git tag
v0.5

当上线后发现v0.5的bug，可以进行hotfix：

$ git flow hotfix start v0.5.1

此时gitflow从master分支上拉出一个hotfix/v0.5.1的分支，接下来在新分支上修改bug。最后执行命令：

$ git flow hotfix finish v0.5.1

这样hotfix/v0.5.1被merge到master/develop分支，打好v0.5.1这个tag，删除这个分支，切换回develop分支。
之后又是新一次的轮回，启动正常的feature开发。