git flow
目录
1.Git flow
2.Github flow
3.Gitlab flow
1.Git flow
主要特点
1.存在两个长期分支
主分支master
开发分支developmaster用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；develop用于日常开发，存在最新的开发版。
2.存在三种短期分支
功能分支(feature branch)
补丁分支(hotfix branch)
预发分支(release branch) 评价
Git flow的有点是清晰可控，缺点是相对复杂，需要同时维护两个长期分支。大多数工具都将master当做默认分支，可以开发是在develop分支进行的，这导致经常要切换分支。
这个模式是基于“版本发布”的，目标是一段时间以后产出一个新版本。但是很多网站项目是“持续发布”，代码一有变动，就部署一次，这时，master和develop分支的差别不大，没必要维护两个长期分支。
2.Github flow
Github flow是Git flow的简化版，专门配合“持续发布”。主要特点
Github flow只要一个长期分支，就是master，因此用起来比较简单。
1.根据需求，从master拉出新分支，不区分功能分支或补丁分支。
2.新分支开发完成后，或者需要讨论的时候，就向master发起一个pull request
3.pull request的过程中，你可以不断提交代码。
4.你的pull request被接受，合并进master，重新部署后，原来拉出来的分支就被删除。
评价
Github flow的最大优点就是简单，对于“持续发布”的产品，可以说是最合适的流程。
问题在于它认为master分支的更新与产品的发布是一致的。master分支的最新代码，默认就是当前线上的代码。
可是，有时候并非如此，代码合并进入master分支，并不代表它就能立刻发布。比如，提交Apple的APP，审核需要一段时间才能上架，这时，如果还有新的代码提交，master分支就会与刚发布的版本不一致。
3.Gitlab flow
Gitlab flow是Git flow与Github flow的综合主要特点
Gitlab flow的最大原则叫做“上游优先”，即只存在一个主分支master，它是所有其他分支的上游，只有上游分支采纳的代码变化，才能应用到其他的分支。
1、持续发布
对于”持续发布”的项目，它建议在master分支以外，再建立不同的环境分支。比如，”开发环境”的分支是master，”预发环境”的分支是pre-production，”生产环境”的分支是production。
开发分支是预发分支的”上游”，预发分支又是生产分支的”上游”。代码的变化，必须由”上游”向”下游”发展。比如，生产环境出现了bug，这时就要新建一个功能分支，先把它合并到master，确认没有问题，再cherry-pick到pre-production，这一步也没有问题，才进入production。
只有紧急情况，才允许跳过上游，直接合并到下游分支。
2、版本发布
对于”版本发布”的项目，建议的做法是每一个稳定版本，都要从master分支拉出一个分支，比如2-3-stable、2-4-stable等等。
以后，只有修补bug，才允许将代码合并到这些分支，并且此时要更新小版本号。
补充：Pull Request/ Merge Request
当要发起一个Pull Request,需要请求(Request)另一个开发者，来pull你仓库中的一个分支到他的仓库中。这需要提供4个信息（源仓库、源分支、目的仓库、目的分支），以发起Pull Request。
实际项目
我们项目中使用的是Gitlab flow，对master和develop开启权限，没有权限的开发者不能合并到develop分支上面，需要发起merge request请求。Gitlab flow对分支的管理比较严谨，所以整个流程会比较复杂。如果有新人加入开发，就可以通过控制他的权限来控制代码的质量。
而我们公司的另一个项目组使用的是Git flow，只维护master分支，所有的代码都自行合并到master上。这种方式比较适合少人开发，或者开发者都是项目主力的情况下，不需要进行review代码的这一步。提交合并代码的流程变得简单许多。不过这样，就需要所有的开发者对自己的bug负责，提交的代码如果影响到其他人的代码，也是不允许的。
建议是用sourceTree工具来处理代码的提交合并。
参考资料：
http://www.ruanyifeng.com/blog/2015/12/git-workflow.html
https://lucamezzalira.com/2014/03/10/git-flow-vs-github-flow/
http://blog.jobbole.com/76867/
http://www.ituring.com.cn/article/56870