這里使用 gitlab 做服務(wù)器, 客戶端主要使用 git extensions.

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

gitlab 項(xiàng)目成員類型:

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

1. guest : 能在 gitlab 網(wǎng)頁上創(chuàng)建 issue, 查看 wiki

2. reporter: 權(quán)限比guest更大, 能 clone 項(xiàng)目

3. developer: 能commit代碼

4. maintainer: 能進(jìn)行項(xiàng)目成員管理, 能進(jìn)行分支保護(hù)管理

5. owner: 能刪除項(xiàng)目, 能刪除 issue.

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

gitlab 項(xiàng)目可見性

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

新建項(xiàng)目首先要選定項(xiàng)目的可見性, 有如下幾種分類:

1. private -私有項(xiàng)目, 企業(yè)內(nèi)的項(xiàng)目一般都選這個(gè)類型, 只有項(xiàng)目組成員能訪問

2. internal- 內(nèi)部項(xiàng)目, 只要具有登錄權(quán)限的用戶都能看到代碼

3. public -公開項(xiàng)目, 不需登錄即可 clone 代碼.

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

分支策略管理

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

這里采用了 gitflow 的分支管理策略, 很多git客戶端都提供 gitflow 插件, 我倒不推薦使用這些插件, 采用標(biāo)準(zhǔn)的新建分支/合并/創(chuàng)建tag命令即可.

分支名	分支類型	是否為保護(hù)分支?	分支鏈路	描述
master	main類型分支(長久分支)	保護(hù)分支	release-xxx => master	這個(gè)分支的代碼即為當(dāng)前生產(chǎn)環(huán)境的代碼
develop	main類型分支(長久分支)	如果要加入code review環(huán)境, 應(yīng)該將這個(gè)分支設(shè)為保護(hù)分支,否則為非保護(hù)分支	初始化時(shí)來源于 master, 日常: feature-xxx => develop	這個(gè)分支始終保留著最新的開發(fā)代碼, 階段性地合并 feature 系列分支
feature系列分支	supporting類型分支(短生命周期)	非保護(hù)分支	develop=>feature-xxx=>develop	每個(gè)人領(lǐng)feature任務(wù), 為該任務(wù)建立一個(gè)feature分支. 命名規(guī)范應(yīng)該時(shí)候 feature-xxx, 分支開發(fā)完畢要合并到develop分支. 開發(fā)人員平時(shí)應(yīng)該在feature系列分支上工作, 假設(shè)下個(gè)大版本中包含5個(gè)feature, 只有這5個(gè)feature都合并到 develop 之后, 才能合并下下大版的feature.
release系列分支	supporting類型分支(短生命周期)	非保護(hù)分支	develop=>release-xxx =>(master和develop)	當(dāng) develop 分支完成了預(yù)期feature的合并, 就可以對 develop 做快照, 生成一個(gè) release 分支. develop 分支可以繼續(xù)演進(jìn). release 編譯之后要進(jìn)行QA+UAT測試. QA和UAT中出現(xiàn)的bug,也是也要在這個(gè)分支上解決. 所有問題解決后, 就正式發(fā)版, 需要及時(shí)合并到 master 分支, 并對master分支打 tag. 然后要合并到 develop 分支, 因?yàn)閐evelop分支可能已經(jīng)要修改, 所以需要手工解決代碼沖突.
bugfix系列分支	supporting類型分支(短生命周期)	非保護(hù)分支	master => bugfix-xxx => (master和develop)	當(dāng)線上有bug, 應(yīng)基于master生成bugfix-xxx 分支, 解決了該bug后, 要merge 會 master, 并為master打tag. 然后在merge 會 develop 分支, 并刪除該bugfix分支

對于 feature/bugfix/release系列分支, 可以考慮定期將那些結(jié)束了很長時(shí)間的分支及時(shí)刪除, 歷史分支太多會加大管理負(fù)擔(dān).

feature 系列分支的命名規(guī)范應(yīng)該為: feature-大版本-功能名

release系列分支的命名規(guī)范應(yīng)該為: release-大版本

bugfx 系列分支的命名規(guī)范應(yīng)該為: bugfix-bug名

master 分支上的每次變更,都應(yīng)及時(shí)打上 tag

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

tag管理

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

git extensions 創(chuàng)建tag的方法是, 在 commit history 區(qū)上選中任一個(gè) commit后, 在右鍵菜單中都可以使用create tag 打tag了, 默認(rèn)情況下, git push并不會上傳 tag 到服務(wù)器上, 需要在push時(shí)打開上傳 tag 選項(xiàng)

git extensions 左側(cè)導(dǎo)航樹默認(rèn)僅僅顯示local和remote的分支, 不顯示tag, 可以打開那個(gè)顯示tag的開關(guān)

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

code review 流程

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

基于 gitflow 管理, 最好的code review應(yīng)該是在merge feature代碼到 develop 的時(shí)候. 為了防治代碼未經(jīng)code review就被合并, 最好是將 develop 分支設(shè)置為保護(hù)分支. code review 的流程是:

1. 開發(fā)人員在 feature-xxx 分支開發(fā)完成后, push 代碼到gitlab 服務(wù)器上

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

3. code reviewer登錄 gitlab, 審核代碼

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

參考

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

Git 在團(tuán)隊(duì)中的最佳實(shí)踐--如何正確使用Git Flow

關(guān)于GITLAB若干權(quán)限問題

總結(jié)

以上是生活随笔為你收集整理的使用 gitlab 进行代码管理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。