如何使用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>