如何使用gitlab的flow以及代码review
来自： http://mojito515.github.io/blog/2016/03/09/ru-he-shi-yong-gitlabde-flowyi-ji-dai-ma-review/
Git工作流
我们在工作中经常用到git来管理自己的代码，也会涉及到多人协作的场景， 被广泛使用的三种工作流如下：
-
Git flow
-
Github flow
-
Gitlab flow
以下只简单总结三种flow的特点和弊端,具体的介绍和比较请移步阮一峰老师的文章 《Git工作流》
Git flow
典型的长期维护master分支和develop分支，因为是FDD（功能驱动开发），所以会在协作开发中衍生出 功能分支（feature branch）、补丁分支（hotfix branch）、预发版分支（release branch），完成之后会合并到develop或者master分支，之后删除。优点是清晰可控，但这个模式是基于“版本发布”的，目标是一段时间产出一个新版本，不适合“持续发布”的网站开发。
Github flow
只有一个master长期分支，需要协同的人可以fork代码（其实就是新建了一个自己的分支，并且pull到了master上的代码），当你的功能需求代码完成之后，或者需要讨论的时候，就向master发起一个pull request。通知到别人评审、讨论、review你的代码，方便的是，在request提交之后评审的过程中，你还可以提交代码。等到你的request被accept，分支会合并到master，重新部署后，你原来的那个分支就可以删除啦。缺点是有时你的产品发布的代码版本和你master最新的版本并不是一个（比如因为苹果审核需要时间，那么你的代码就需要另一个分支来保留线上版本）。
Gitlab flow
引入了“上游优先”（upsteam first）的原则。只存在一个主分支master，它是所有其他分支的"上游"。只有上游分支采纳的代码变化，才能应用到其他分支。版本发布"的项目，建议的做法是每一个稳定版本，都要从master分支拉出一个分支。使用gitlab建立group project，可以将成员全部添加进小组中，每个人的提交都以分支合并进master分支的方式进行，我们可以将master设置成protected branch，这样就做到了强制代码review的机制，利于提升代码的质量。Issue 用于 Bug追踪和需求管理。建议先新建 Issue，再新建对应的功能分支。
Gitlab如何使用
首先，在gitlab的console中创建工程，创建好后会有如下图的命令提示，告知你怎样在本地创建代码项目并push（使用sourcetree更简单）：
项目创建完成之后，给项目添加成员：
把master分支设置成受保护分支，这样成员在提交代码的时候，只能先提交merge request（强制做代码review）：
在本地，以developer的身份push代码，会显示不成功：
正常流程中，是先本地从master上拉取新建分支：
当有代码需要提交push的时候，在gitlab的console中创建merge request 完成代码向master分支的提交：
负责review的小伙伴可以对代码进行评论，在accept之前，该分支中再次push的commit都归属于这次merge request。accept之后，分支自动合并到master分支中（可以勾选直接删除merge的功能分支）:
至此，一次完整的代码提交过程就完成了。当然，在项目上线之后，会有“下游”的分支，例如 生产版本的分支、预生产版本的分支也会加入到protected branch的行列。
</div>