Git 分支設(shè)計(jì)規(guī)范
? ? ? ? ? ? ? ? ? ? 概述
這篇文章分享 Git 分支設(shè)計(jì)規(guī)范，目的是提供給研發(fā)人員做參考。
規(guī)范是死的，人是活的，希望自己定的規(guī)范，不要被打臉。
在說 Git 分支規(guī)范之前，先說下在系統(tǒng)開發(fā)過程中常用的環(huán)境。| 簡稱 | 全稱 |
|---|---|
| DEV | Development environment |
| FAT | Feature Acceptance Test environment |
| UAT | User Acceptance Test environment |
| PRO | Production environment |
- DEV 環(huán)境：用于開發(fā)者調(diào)試使用。
- FAT 環(huán)境：功能驗(yàn)收測試環(huán)境，用于測試環(huán)境下的軟件測試者測試使用。
- UAT 環(huán)境：用戶驗(yàn)收測試環(huán)境，用于生產(chǎn)環(huán)境下的軟件測試者測試使用。
- PRO 環(huán)境：就是生產(chǎn)環(huán)境。
比如，項(xiàng)目域名為：http://www.abc.com，那么相關(guān)環(huán)境的域名可這樣配置：
DEV 環(huán)境：本地配置虛擬域名即可
- FAT 環(huán)境：
http://fat.abc.com - UAT 環(huán)境：
http://uat.abc.com - PRO 環(huán)境：
http://www.abc.com
接下來，針對不同的環(huán)境來設(shè)計(jì)分支。
分支
| 分支 | 名稱 | 環(huán)境 | 可訪問 |
|---|---|---|---|
| master | 主分支 | PRO | 是 |
| release | 預(yù)上線分支 | UAT | 是 |
| hotfix | 緊急修復(fù)分支 | DEV | 否 |
| develop | 測試分支 | FAT | 是 |
| feature | 需求開發(fā)分支 | DEV | 否 |
master 分支
master 為主分支，用于部署到正式環(huán)境（PRO），一般由 release 或 hotfix ?分支合并，任何情況下不允許直接在 master 分支上修改代碼。
release 分支
release 為預(yù)上線分支，用于部署到預(yù)上線環(huán)境（UAT），始終保持與 master 分支一致，一般由 develop 或 hotfix 分支合并，不建議直接在 release 分支上直接修改代碼。
如果在 release 分支測試出問題，需要回歸驗(yàn)證 develop 分支看否存在此問題。
hotfix 分支
hotfix 為緊急修復(fù)分支，命名規(guī)則為 hotfix- 開頭。
當(dāng)線上出現(xiàn)緊急問題需要馬上修復(fù)時(shí)，需要基于 release 或 master 分支創(chuàng)建 hotfix 分支，修復(fù)完成后，再合并到 release 或 develop 分支，一旦修復(fù)上線，便將其刪除。
develop 分支
develop 為測試分支，用于部署到測試環(huán)境（FAT），始終保持最新完成以及 bug 修復(fù)后的代碼，可根據(jù)需求大小程度確定是由 feature 分支合并，還是直接在上面開發(fā)。
一定是滿足測試的代碼才能往上面合并或提交。
feature 分支
feature 為需求開發(fā)分支，命名規(guī)則為 feature- 開頭，一旦該需求上線，便將其刪除。
這么說可能有點(diǎn)不容易理解，接下來舉幾個(gè)開發(fā)場景。
開發(fā)場景
新需求加入
有一個(gè)訂單管理的新需求需要開發(fā)，首先要?jiǎng)?chuàng)建一個(gè) feature-order 分支，問題來了，該分支是基于哪個(gè)分支創(chuàng)建？
如果 存在 未測試完畢的需求，就基于 master 創(chuàng)建。
如果 不存在 未測試完畢的需求，就基于 develop 創(chuàng)建。
需求在
feature-order分支開發(fā)完畢，準(zhǔn)備提測時(shí)，要先確定develop不存在未測試完畢的需求，這時(shí)研發(fā)人員才能將將代碼合并到develop（測試環(huán)境）供測試人員測試。測試人員在
develop（測試環(huán)境） 測試通過后，研發(fā)人員再將代碼發(fā)布到release（預(yù)上線環(huán)境）供測試人員測試。測試人員在
release（預(yù)上線環(huán)境）測試通過后，研發(fā)人員再將代碼發(fā)布到master（正式環(huán)境）供測試人員測試。測試人員在
master(正式環(huán)境) 測試通過后，研發(fā)人員需要?jiǎng)h除feature-order分支。
普通迭代
有一個(gè)訂單管理的迭代需求，如果開發(fā)工時(shí) < 1d，直接在 develop 開發(fā)，如果開發(fā)工時(shí) > 1d，那就需要?jiǎng)?chuàng)建分支，在分支上開發(fā)。
開發(fā)后的提測上線流程 與 新需求加入的流程一致。
修復(fù)測試環(huán)境 Bug
在 develop 測試出現(xiàn)了Bug，如果修復(fù)工時(shí) < 2h，直接在 develop 修復(fù)，如果修復(fù)工時(shí) > 2h，需要在分支上修復(fù)。
修復(fù)后的提測上線流程 與 新需求加入的流程一致。
修改預(yù)上線環(huán)境 Bug
在 release 測試出現(xiàn)了Bug，首先要回歸下 develop 分支是否同樣存在這個(gè)問題。
如果存在，修復(fù)流程 與 修復(fù)測試環(huán)境 Bug流程一致。
如果不存在，這種可能性比較少，大部分是數(shù)據(jù)兼容問題，環(huán)境配置問題等。
修改正式環(huán)境 Bug
在 master 測試出現(xiàn)了Bug，首先要回歸下 release 和 develop 分支是否同樣存在這個(gè)問題。
如果存在，修復(fù)流程 與 修復(fù)測試環(huán)境 Bug流程一致。
如果不存在，這種可能性也比較少，大部分是數(shù)據(jù)兼容問題，環(huán)境配置問題等。
緊急修復(fù)正式環(huán)境 Bug
需求在測試環(huán)節(jié)未測試出 Bug，上線運(yùn)行一段時(shí)候后出現(xiàn)了 Bug，需要緊急修復(fù)的。
我個(gè)人理解緊急修復(fù)的意思是沒時(shí)間驗(yàn)證測試環(huán)境了，但還是建議驗(yàn)證下預(yù)上線環(huán)境。
如果
release分支存在未測試完畢的需求，就基于master創(chuàng)建hotfix-xxx分支，修復(fù)完畢后發(fā)布到master驗(yàn)證，驗(yàn)證完畢后，將master代碼合并到release和develop分支，同時(shí)刪掉hotfix-xxx分支。如果
release分支不存在未測試完畢的需求，但develop分支存在未測試完畢的需求，就基于release創(chuàng)建hotfix-xxx分支，修復(fù)完畢后發(fā)布到release驗(yàn)證，后面流程與上線流程一致，驗(yàn)證完畢后，將master代碼合并到develop分支，同時(shí)刪掉hotfix-xxx分支。如果
release和develop分支都不存在未測試完畢的需求， 就直接在develop分支上修復(fù)完畢后，發(fā)布到release驗(yàn)證，后面流程與上線流程一致。
并行提測
在一個(gè)項(xiàng)目中并行開發(fā)了兩個(gè)需求，并行提測，但是上線日期不同。
我能想到的兩種方案：
- 再部署一套可供測試人員測試的分支
- 使用
git cherry-pick“挑揀”提交
對于并行提測，你有好的方案嗎？歡迎留言。
Commit 日志規(guī)范
提交信息一定要認(rèn)真填寫！
建議參考規(guī)范：
比如：fix(首頁模塊)：修復(fù)彈窗 JS Bug。
type 表示 動作類型，可分為：
- fix：修復(fù) xxx Bug
- feat：新增 xxx 功能
- test：調(diào)試 xxx 功能
- style：變更 xxx 代碼格式或注釋
- docs：變更 xxx 文檔
- refactor：重構(gòu) xxx 功能或方法
scope 表示 影響范圍，可分為：模塊、類庫、方法等。
subject 表示 簡短描述，最好不要超過 60 個(gè)字，如果有相關(guān) Bug 的 Jira 號，建議在描述中加上。
小結(jié)
暫時(shí)就想到這么多，規(guī)范這東西不是一成不變的，供參考。
推薦閱讀：
喜歡我可以給我設(shè)為星標(biāo)哦
好文章，我?在看?
