這里使用 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, 審核代碼
=============================
參考
=============================