群組 / 項目
群組和項目的關系我們可以簡單的理解成文件夾和文件的關系。一個群組可以包含一個或多個項目。
使用群組，可以將相關的項目組合在一起，並允許成員同時訪問多個項目。
群組也可以嵌套在子組中，建議最多嵌套一層。
項目的命名我們建議前綴組的名稱。
項目的所屬關系可以轉移
可見級別
創建群組或者創建項目時，需要設置可見級別，默認為 Internal。有三種級別可選：
1.private。只有項目成員訪問才允許訪問該項目。必須明確給每一個用戶授權訪問。
2.Internal。任何已登錄的用戶均可以訪問該項目。
3.public。任何人都可以訪問該項目，無論是否登錄。
對於安全類的項目，應該保證知道的人越少越好，Group 和 Project 的訪問級別均應該設置為 Private。
對於模板和純技術類項目，應該設置為 public 或者 internal。
還有一類項目，希望所有人知道它的存在，可以瀏覽，可以搜索，但是不希望所有人都能夠獲取它的代碼。那我們可以這樣來設置：
項目的訪問級別是 Internal。
項目的（Settings（設置） -> General（常規） -> Permissions（權限） -> Repository（倉庫）） 權限設置為： Only Project Members。
權限
GitLab 的權限分為群組和項目權限。項目的默認權限繼承群組的權限。GitLab有一下五種身份設置，不同的身份分別具有不同的操作權限
1.所有者。
2.主程序員。
3.開發人員。
4.報告者。
5.訪客。
因為項目的權限設置是繼承組的權限，如果組的權限不合理，可以進一步更改。
Git實踐-分支管理
主分支
在版本控制系統中有兩個永久存在的分支，即master分支和dev分支。
我們認為遠程的master分支上HEAD指向的代碼都是可發布的。而遠程dev分支上HEAD指向的代碼總是反應了下一個版本所要添加功能的最新的代碼變更。
當dev分支上的代碼達到一個穩定狀態，准備發布時，所有代碼的變更都應合並到master分支，然后打上發布版本號的tag。所以，每次代碼合並到master分支時，它既是一個人為定義的新的發布產品。
輔助分支
為幫助團隊成員間的並行開發，功能的簡單跟蹤，產品的發布准備事宜，以及快速的解決線上問題，我們會采用另外一種輔助性的分支，這些輔助性分支往往只有有限的生命周期，因為他們最終會被刪除。輔助分支有幾種不同的類型
1.功能分支
用於開發未來某個版本新的功能。只要功能還在開發，它就應該一直存在。功能分支可以從主要分支建立，也可以並行與主要分支建立，但是最終必須合並到主要分支中。功能分支可以隨意命名，但是除了master，dev，release，hotfix外。
功能分支只存在於開發者的本地版本庫。
2.release分支
從dev分支去建立release分支，release分支必須合並到dev分支和master分支。
release分支用於支持一個新版本的發布。在release分支創建好后，就會獲取到一個決定好的即將發布的版本號。在此之前，dev分支的代碼反應出了下一個版本的代碼變更
當release分支的准備成為一個真正的發布版本時，我們必須將release分支合並回master分支（因為master分支的每一次提交都是預先定義好的一個新版本），然后為這次提交打tag，為將來查看歷史版本做准備。最后將在release分支做得更改也合並到dev分支，這樣的作用是使將來的其他版本也會包含這些已經解決了的Bug。
3.Hotfix分支
Hotfix分支從master分支進行創建。最后必須合並回dev分支和master分支。
Hotfix分支在某種程度上非常像release分支，他們都是為新版本發布做准備。Hotfix分支是基於當前生產環境的產品的一個Bug急需解決而創建的。當某個版本的產品有一個嚴重Bug需要立即解決，Hotfix分支需要從master分支上該版本對應的tag上進行建立，因為這個tag標記了產品的版本。
完成工作之后，解決掉的bug代碼需要合並回master分支，同時也需要合並到dev分支，目的是保證在下一版本中該Bug已經被解決。
上述的每一個分支都有其特殊目的，也綁定了嚴格的規則：哪些分支是自己的拉取分支，哪些分支是自己的目標合並分支。從技術角度看，這些分支的特殊性沒有更多的含義。只是按照我們的使用方式對這些分支進行了歸類。他們依舊是原Git分支的樣子。
commits / push
工作中我們每天最少一次推送，而每次修改都可以作為一次提交。
合並請求
合並請求是GitLab作為代碼協作和版本控制平台的基礎。顧名思義：一個請求，以合並一個分支到另一個分支。
合並申請功能來通知團隊成員你已經完成了可一個功能開發。當開發者完成開發的功能后，然后發起合並申請。這可以讓被通知到人去review代碼並合並這些代碼到master分支不過合並申請功能可不止發送通知這么簡單——它可以用來作為討論提出申請的功能的專用論壇。如果代碼有任何問題，團隊成員們可以提出反饋，甚至推送（push）提交來小小的修改代碼。合並申請功能可以追蹤這些事情。
請求合並的基本流程大致如下：
開發者在本地倉庫創建一個功能開發專用的分支。
開發者將分支推送到遠程倉庫
開發者發起合並申請
團隊成員review代碼，展開討論或者修改他們。
項目維護者合並該分支到正式倉庫然后關閉合並申請。
敏捷開發
GitLab是敏捷開發的一個高效實踐工具，而且在不斷的發展和迭代。其作用主要體現在以下兩個功能中
issues
GitLab對issues的介紹是：issues是添加需要在項目中改進或解決的事物的地方。可能是要討論的錯誤，任務或想法。issues是可搜索和可過濾的。
issues可以是一個Bug，可以是一個功能，可以用開發布任務，需求調研或者是某個類或者函數的重構。
強烈建議跟項目有關系的事情，不要放在腦子里，放在issues中。而我們每天上班的第一件事就是看issues，了解項目相關的問題。
里程碑
里程碑規定項目的任務清單，任務的開始時間和結束時間。可以多個里程碑並行。
里程碑是項目整體進度的體現。項目經理通過關注里程碑的規划，進度對項目進行相應的調整。
除了以上操作，GitLab還有很多高深的操作，例如CI持續集成，鏡像等，那就需要大家自己去探索啦。
參考文章：GitLub操作