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