git glow
简单介绍
git-flow,是一个工具，是一种规范
Git Flow是构建在Git之上的一个组织软件开发活动的模型，是在Git之上构建的一项软件开发最佳实践。Git Flow是一套使用Git进行源代码管理时的一套行为规范和简化部分Git操作的工具。
所以说，git-flow 是一个规则，一种约定，一种规范，并不是什么洪水猛兽， 是提高你使用git技术的一个进阶实践。
git-flow 基于git本身的分支管理机制
所以，你必须先了解什么是git的分支(branch).请看图
因为时间关系，我们假设你已经知道什么是branch， git-flow就是通过在一个项目里划分不同的分支，来实现功能开发、bug修复、版本发布，以及开发过程中的冲突处理等。
（如果觉得这个描述有点绕，那么暂时不用理解它。）
git-flow把分支划分了几个类别
Master
就是平时我们看到的master，项目的主要分支，对外的第一门面。
所有外人浏览你的项目，使用你的项目，第一时间都是看到master。
你可以把它理解成 稳定无bug发布版 。（任何时候都ready to deploy）
所以，git-flow 要求我们不能在master下做开发。
Develop
处于功能开发最前线的版本，查看develop分支就能知道下一个发布版有哪些功能了。
develop一开始是从master里分出来的，并且定期会合并到master里，
每一次合并到master，表示我们完成了一个阶段的开发，产生一个稳定版。
同样的，develop下也不建议直接开发代码，develop代表的是已经开发好的功能
的回归版本（为什么说回归？）
Feature
带着develop处的疑问，我们在feature里为你解答。（有点长，别不看）
feature的作用是为每一个新功能从develop里创建出来的一个分支。
例如小明和小白分别做两个不相干的功能，就应该分别创建两个分支，
各自开发完以后，先后合并到develop里，这就叫做回归。
在这个过程里，小明小白不需要任何的沟通，分别并行地开发，
git-flow能很好的处理好分支间并行开发的关系。
而develop，则会在适当的时候，由合适的人，合并到master，作为下一个稳定版本。
Hotfix
以上3种以外，还有一个很重要的类型，hotfix。
它是用来修复紧急bug的，而bug通常是来自线上的，
所以hotfix分支是从master里创建出来的，并且，在bug修改好以后，
要同时合并到master和develop，这一点需要特别注意。
Release
release更多倾向与版本发布，项目上线前的一些全面测试以及上线准备。
同样也肩负着版本归档，回滚支持等。
开始使用
上面说到了，git-flow本质只是一个约定，所以你完全可以在现行的git命令行里， 手动地完成全部git-flow操作，（手动创建、合并分支等）， 重点是遵守git-flow规范，遵守命名约定和分支管理流程。
不过，git-flow早就有插件了。参看这个文章：
http://blog.163.com/tod_zhang/blog/static/1025522142012913113957679/
安装了这个插件，你的git就多了一系列方便的命令，比如：
git flow init
git flow feature start
git flow feature finish
等等。
不过，我觉得这个插件还是不够方便，我墙裂推荐你们都用 SourceTree 。
如果我要推荐一个git-flow客户端，我会推荐SourceTree。
如果我要推荐一个git客户端，那我还是推荐SourceTree。
没错，SourceTree是专门为git-flow开发的git客户端，它涵盖了所有git本身的功能，
所以即使你不flow，你也可以使用SourceTree来管理你的git项目。
官方网站：
至于如何下载、安装、/* 破解 */ ，这些内容就交给各位自行baidu了。
详细说明
那么下面我们来实际操作一次，看看SourceTree如何帮助我们使用git-flow
1.小明创建了一个新项目，就做 Demo，并且用SourceTree来打开它。如果这一步都 不会，你还是别做开发了。
（一个新的项目，就不发图了）
2.小明为了使用git-flow，需要为git项目做一次初始化。
这些可以改动的地方，为了方便其他协作人员，还是用默认好了。
3.初始化后，会自动切换到develop分支，接下来，小明要发一个新功能
注意那个 Git Flow 按钮，所有flow的功能都是从那里开始操作的。 在弹出的窗口里输入功能的名字即可，小明决定开发一个 test1 功能。
这时，左侧的菜单已经看到分支切换到test1了（有加粗效果）
4.然后小明开始了暗无天日的编码过程，千辛万苦后写了一行readme
接下来我们演示一下如何提交修改
这个界面十分清晰地告诉你本地没有commit的代码，
当然了，这仅仅是commit到本地，因为这始终是git，我们还需要push到远端。
可以在左侧看到，我们暂存了多少个commit。 按照图上流程，选择你要push 的分支，你也可以一次选择多个， 在这里我们先push 功能分支test1 。
5.提交过几次代码之后，小明认为功能已经开发完毕，可以回归到develop了
注意，这个时候，只有test1的代码是改变了的，develop还是停留在小明创建feature时的状态。
为了安全起见，每次合并之前，最好pull一下develop，再次不表。（SourceTree拉取）
那么我们现在把开发好的test1合并到develop：
整个界面很简单，就一个操作，实际上，它背后做了很多。 (@ -_-)
如无意外，test1里的改动会合并到develop里，并且会删除本地的test1，
然后把分支切换到develop，这时候我们应该能看到整个test1期间的变动数目：
接下来你应该立即把develop的改动push到远端！
OK，这就是一个功能开发的完整流程，就算有多个功能在并行开发，
通过git-flow的协调，都能互不干扰地开发，最终全部作用到develop上。
昨天才看到《gitflow有害论》呢：http://insights.thoughtworkers.org/gitflow-consider-harmful/?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io 讲得也是满有道理的，不利于持续集成。个人觉得gitflow也是比较复杂。
@klesh 简单看了下，其实他表达的都不是git flow的缺陷，都是人为的缺陷，比如我就每天从develop里pull到正在开发的feature， 自豪地采用 CNodeJS ionic
@captainblue2013 从 develop pull 到 feature 不是问题，关键是 feature 生命周期太长的话（事实上一般不会短，太短就没必要开个分支了），不能持续 merge 到 develop 从而导致 ci 无法实施。如文中所提到，feature B 修改了某处共用的代码，那在这个 feature B merge 到 develop 之前，feature A 用的还是老代码。这个怎么解决？反过来说若持续不断地将 feature merge 到 develop 去做 ci, 那 feature branch 还有存在的必要吗？何不直接在 develop 上工作？
@klesh 实际上这只是一种极端的情况下带来的缺陷吧，对于几十人的开发团队，很难做到持续集成，带来的混乱是非常不好处理的。可能对于项目所处的阶段也有关系，对于已经稳定在线上运行的项目，很少有feature之间相互很多依赖这种情况。 而对于新功能的开发，一个不受影响的“封闭”环境，能大大简化了开发复杂度。
我们团队现在也是这种模式，master分支用来对外发布，简称稳定版本;beta分支用来对内发布，简称内侧版本；dev分支用来开发，主要承担集成测试的任务；每个工程师根据自己需要做的功能，从dev开新分支进行开发，工程师新开的分支我们简称功能分支，功能分支只能对dev分支提交合并请求。master和beta分支由专人管理，master分支必须是从beta分支提交合并请求，beta分支必须是从dev分支提交合并请求。只有在修复紧急bug的情况下，才能从master或者beta开新分支来进行修复。
