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

?

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

gitlab 項目成員類型:

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

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

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

3. developer: 能commit代碼

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

5. owner: 能刪除項目, 能刪除 issue.?

?

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

gitlab 項目可見性

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

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

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

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

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

?

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

分支策略管理

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

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

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

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

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

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

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

?

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

tag管理

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

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

?

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

?

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

code review 流程

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

基于 gitflow 管理, 最好的code review應(yīng)該是在merge feature代碼到 develop 的時候. 為了防治代碼未經(jīng)code review就被合并, 最好是將 develop 分支設(shè)置為保護分支. 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 在團隊中的最佳實踐--如何正確使用Git Flow?

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

?

轉(zhuǎn)載于:https://www.cnblogs.com/harrychinese/p/gitlab.html

總結(jié)

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

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