使用 gitlab 進行代碼管理

這裡使用 gitlab 做伺服器, 用戶端主要使用 git extensions. 

=============================

gitlab 項目成員類型:

=============================

1. guest : 能在 gitlab 網頁上建立 issue, 檢視 wiki

2. reporter: 權限比guest更大, 能 clone 項目

3. developer: 能commit代碼

4. maintainer: 能進行項目成員管理, 能進行分支保護管理

5. owner: 能删除項目, 能删除 issue. 

=============================

gitlab 項目可見性

=============================

建立項目首先要標明項目的可見性, 有如下幾種分類:

1. private -私有項目, 企業内的項目一般都選這個類型, 隻有項目組成員能通路

2. internal- 内部項目, 隻要具有登入權限的使用者都能看到代碼

3. public -公開項目, 不需登入即可 clone 代碼. 

=============================

分支政策管理

=============================

這裡采用了 gitflow 的分支管理政策,  很多git用戶端都提供 gitflow 插件, 我倒不推薦使用這些插件, 采用标準的建立分支/合并/建立tag指令即可. 

分支名	分支類型	是否為保護分支?	分支鍊路	描述
master	main類型分支(長久分支)	保護分支	release-xxx => master	這個分支的代碼即為目前生産環境的代碼
develop	main類型分支(長久分支)	如果要加入code review環境, 應該将這個分支設為保護分支,否則為非保護分支	初始化時來源于 master,  日常: feature-xxx => develop	這個分支始終保留着最新的開發代碼, 階段性地合并 feature 系列分支
feature系列分支	supporting類型分支(短生命周期)	非保護分支	develop=>feature-xxx=>develop	每個人領feature任務, 為該任務建立一個feature分支. 命名規範應該時候 feature-xxx, 分支開發完畢要合并到develop分支.  開發人員平時應該在feature系列分支上工作, 假設下個大版本中包含5個feature, 隻有這5個feature都合并到 develop 之後, 才能合并下下大版的feature.
release系列分支	supporting類型分支(短生命周期)	非保護分支	develop=>release-xxx => (master和develop)	當 develop 分支完成了預期feature的合并, 就可以對 develop 做快照, 生成一個 release 分支. develop 分支可以繼續演進. release 編譯之後要進行QA+UAT測試.  QA和UAT中出現的bug,也是也要在這個分支上解決.  所有問題解決後, 就正式發版, 需要及時合并到 master 分支, 并對master分支打 tag. 然後要合并到 develop 分支, 因為develop分支可能已經要修改, 是以需要手工解決代碼沖突.
bugfix系列分支	supporting類型分支(短生命周期)	非保護分支	master => bugfix-xxx => (master和develop)	當線上有bug, 應基于master生成bugfix-xxx 分支, 解決了該bug後, 要merge 會 master, 并為master打tag. 然後在merge 會 develop 分支, 并删除該bugfix分支

對于 feature/bugfix/release系列分支, 可以考慮定期将那些結束了很長時間的分支及時删除, 曆史分支太多會加大管理負擔. 

feature 系列分支的命名規範應該為: feature-大版本-功能名

release  系列分支的命名規範應該為: release-大版本

bugfx 系列分支的命名規範應該為: bugfix-bug名

master 分支上的每次變更,都應及時打上 tag 

=============================

tag管理

=============================

git extensions 建立tag的方法是, 在 commit history 區上選中任一個 commit後, 在右鍵菜單中都可以使用create tag 打tag了, 預設情況下, git push并不會上傳 tag 到伺服器上, 需要在push時打開上傳 tag 選項

git extensions 左側導航樹預設僅僅顯示local和remote的分支, 不顯示tag, 可以打開那個顯示tag的開關

=============================

code review 流程

=============================

基于 gitflow 管理, 最好的code review應該是在merge feature代碼到 develop 的時候. 為了防治代碼未經code review就被合并, 最好是将 develop 分支設定為保護分支. code review 的流程是:

1. 開發人員在 feature-xxx 分支開發完成後, push 代碼到gitlab 伺服器上

2. 開發人員在 gitlab 網頁發起 merge request 請求, 可以指定 code reviewer , 也可以在描述區使用 @ 的方式抄送給其他人. 

3. code reviewer登入 gitlab, 稽核代碼

=============================

參考 

=============================

​​Git 在團隊中的最佳實踐--如何正确使用Git Flow ​​

​​關于GITLAB若幹權限問題​​