概述
這篇文章分享 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 號，建議在描述中加上。
小結
暫時就想到這么多，規范這東西不是一成不變的，供參考。