GitLab項目管理實踐

羣組 / 項目

　　羣組和項目的關係咱們能夠簡單的理解成文件夾和文件的關係。一個羣組能夠包含一個或多個項目。

　　使用羣組，能夠將相關的項目組合在一塊兒，並容許成員同時訪問多個項目。

　　羣組也能夠嵌套在子組中，建議最多嵌套一層。　　

　　項目的命名咱們建議前綴組的名稱。

　　項目的所屬關係能夠轉移

可見級別

　　建立羣組或者建立項目時，須要設置可見級別，默認爲 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操做

　　　　　Gitlub文檔