GitLab協作流程初稿
標簽（空格分隔）： 工作
准備工作
創建Groups組
PS：后續會將次流程在立項中自動進行。
一個項目立項，開始寫代碼建議建立一個項目組。
並設置權限
在設置界面創建Groups小組
Gitlab中的組和項目有三種訪問權限
Private：只有組成員才能看到
Internal：只要登錄的用戶就能看到
Public：所有人都能看到
為project添加members
添加member
分配權限
進入Members選項卡添加成員到Groups組，添加信息包括（成員郵箱、權限、到期時間）權限分為五種，分別代表五種不同權限。
Guest：可以創建issue、發表評論，不能讀寫版本庫
Reporter：可以克隆代碼，不能提交，QA、PM可以賦予這個權限
Developer：可以克隆代碼、開發、提交、push，RD可以賦予這個權限
Master：可以創建項目、添加tag、保護分支、添加項目成員、編輯項目，核心RD負責人可以賦予這個權限
Owner：可以設置項目訪問權限 - Visibility Level、刪除項目、遷移項目、管理組成員，開發組leader可以賦予這個權限。
group,member與權限
如果你的group下面有多個project，比如有project1，project2，project3，而你的project1邀請了A和B，project2邀請了B和C，那么members A在自己的gitlab主頁就可以看到project1，B可以看到project1和project2，C只能看到project2。如下圖所示
GitLab Code Review機制
GitLab可以在分支合並的時候支持兩種方式：
由Gitlab合並 （推薦）
注意是分支(new branch)不是fork
將源分支(Source branch)Push到遠端，然后在GitLab指定目標分支（Target branch）發起Merge Request，對目標分支（Target branch）擁有Push權限的用戶執行Merge操作，完成合並。
也就是說，使用GitLab進行Code Review就是在分支合並環節發起Merge Request，然后Code Review完成后將代碼合並到目標分支。
優點：適合團隊水平有差異的情況，如和外援共同開發，可以及時發現沖突，適合多人開發，可以用gitlab界面回滾，方便可視化的回滾與分析問題
缺點：有些情況會需要等待review確認
PS：gitlab ee支持多人reivew，gitlab ce支持單人review，后續會通過gitlab+gerrit解決多人reivew。
本地合並（不推薦）
在本地將源分支(Source branch)代碼合並到目標分支（Target branch）然后Push到目標分支（Target branch）。
優點：適合單人開發或精英團隊開發
缺點：多人開發沖突頻繁，阻塞開發，不適合團隊中有不熟悉git的開發的人，會有誤操作，誤刪除分支錯誤合並的風險，適合團隊人少且熟悉git。
主要操作步驟
設置保護分支
將master，develop，release設置為保護分支。
分支名稱約定：
建立dev分支
需求確認后，從master創建develop分支
根據需求拆分分支
開發人員從develop分支創建自己的feature分支進行開發。
新建分支命名規則
人名（漢語拼音）/版本號/功能名稱
例如：yuxinxuan/1.0.1/makeLoginPanel
為什么這么命名？
git客戶端可以折疊，多人開發方便查找自己的分支，可以嘗試不這么命名會導致多人開發查找非常不方便。
為什么要根據功能進行拆分？
方便代碼進行回滾和cherrypick，不要把多個功能寫在一個分支不方便回滾代碼定位問題。
建議建立功能分支后立即創建mr，並標記wip，當完成feature后移除WIP。
Source branch選擇：yuxinxuan/1.0.1/makeLoginPanel（功能分支）
Target branch選擇：develop
feature合並前需要合並dev
feature分支合並到對應的develop分支之前，需要從develop分支合並到feature分支。相關人員進行代碼reivew，點擊accept觸發merge，merge后觸發pipleline自動打包。
定期合並master
master分支發生變更，需要從master分支合並到develop分支、可以考慮定期合並一次。
在提測節點合並到dev
feature分支合並到對應的develop分支之后，發布到測試環境進行測試。
提測后建立release分支
develop分支在測試環境測試通過之后，合並到release分支並發布到預發布環境進行測試。由測試確認提測成功。bug修改完畢以release進行發版。
新建release規則
人名release_版本號_日期
例如：release_1.0.1_20191230
為什么這么命名？
方便區分
修改bug分支命名規則
人名（漢語拼音）/版本號/問題_bugfix
例如：yuxinxuan/1.0.1/問題_bugfix
為什么這么命名，git客戶端可以折疊，多人開發方便查找自己的分支，可以嘗試不這么命名會導致多人開發查找非常不方便。並標記bugfix。
發版本后, 在release分支改線上bug
release分支在預發布環境驗證通過后，release分支合並到master分支並發布到生產環境。發版本后謹慎修改代碼避免線上問題。發版后的bug需要多方確認謹慎修改。
線上bug，修改bug分支命名規則
人名（漢語拼音）/版本號/問題_hotfix
例如：yuxinxuan/1.0.1/問題_hotfix
為什么這么命名，git客戶端可以折疊，多人開發方便查找自己的分支，可以嘗試不這么命名會導致多人開發查找非常不方便。並標記hotfix。
release禁止合入大規模改動，release代碼合入應比dev嚴格，由架構師確認。
強烈建議使用版本號
版本號有利於回溯與二分查找版本之間的bug，也方便持續集成和持續部署
強烈建議規范合並分支流程
可以避免線上問題和回溯問題
參考
https://www.jianshu.com/p/8f392c57d72b?utm_source=oschina-app
https://www.cnblogs.com/ken-io/p/gitlab-code-review-tutorial.html
https://www.cnblogs.com/qianqiu-1026/p/8534897.html
http://www.fwhyy.com/2018/06/Use-the-Merge-Request-working-mode-in-GitLab-in-the-team/