前言
- 本文源自我本人所在團隊Git分支管理的規範指導，不代表任何行業標準
- 本工作流適用於以單元測試爲主、無集成測試的項目代碼分支管理
原則
- 簡潔：儘可能少地創建分支，減少分支管理成本和協同成本
- 快速：保持標籤版本隨時可發佈，通過單元測試及代碼檢視保持主幹的穩定性
分支關係圖
主分支：main
- 主分支會不斷地自動構建並運行單元測試；
- 主分支是相對穩定的分支，需經過嚴格的代碼檢視及單元測試；
- 主分支是受保護的，只有倉庫維護者可以將開發分支合併到主分支，合併行爲即轉測試；
無測試環節的項目代碼，需要通過充分的單元測試保證代碼質量，因此無開發分支
兩大臨時分支
特性分支：feature-xxxx
- 特性分支由開發人員基於主分支創建，用於單個功能特性的開發；
- 特性分支應遵守一特性一分支的原則，便於代碼檢視、需求跟蹤、問題分析等活動；
- 特性分支的命名應爲
feature-[需求編號]，以便於自動關聯需求、需求跟蹤； - 特性分支在單元測試通過後，由作者推送到代碼倉庫，並由作者發起向主分支的合併請求；
- 特性分支的合併，應由倉庫維護者進行代碼檢視後，再合併到開發分支；
問題修復分支：fix-xxxx
- 問題修復分支由開發人員基於開發分支創建，用於單個問題的修復；
- 問題修復分支應遵守一問題一分支的原則，便於代碼檢視、問題跟蹤；
- 問題修復分支的命名應爲
fix-[問題單號]，以便於自動關聯問題單； - 問題修復分支在單元測試通過後，由作者推送到代碼倉庫，並由作者發起向主分支的合併請求；
- 問題修復分支的合併，應由倉庫維護者進行代碼檢視後，再合併到主分支；
臨時分支合併的補充說明
- 特性分支與問題修復分支推送之間，應先從主分支合併最新代碼；
- 合併策略爲rebase，即永遠將自己的提交放在最後，以保持版本歷史記錄的清晰；
- 應謹慎地解決衝突，使用可視化工具如IDEA/WebStorm合併代碼，有必要時叫上產生衝突者結對合並；
可視化工具的代碼合併窗，最左爲我方代碼，中間爲原始代碼，右邊爲第三方代碼； 藍色爲新增的代碼，灰色爲刪除的代碼，紅色爲衝突的代碼，紅色代碼需要謹慎處理。
版本的發佈
主版本標籤：vx.x
- 當主分支的代碼經過評估，準備發佈時，需要打上版本號標籤；
- 主版本標籤以
小寫字母v+主版本號命名，如v1.0； - 版本標籤的目的是爲了可追溯、可關聯，指定版本的發佈以標籤代碼爲準；
版本補丁
補丁分支
- 當發佈的版本出現網上問題、需要緊急修復時，需要基於版本標籤創建補丁分支；
- 補丁分支以
大寫字母V+主版本號命名，如V1.0； - 補丁分支遵循非必要不創建的原則，以減少分支管理的複雜度；
- 補丁分支暫時不創建單獨的CI環境、測試環境，未來視情況部署到預發佈環境；
補丁版本標籤：vx.x.x
- 當生產環境網上問題修復、單元測試、代碼檢視後，需在版本分支上打上補丁版本標籤；
- 補丁版本標籤以
小寫字母v+補丁版本號命名，如v1.0.1；
爲保證版本管理的簡潔性，網上問題應儘量在主版本中修改，酌情發佈補丁 考慮到網上問題的快速修復要求，暫時不限制補丁版本的代碼直接合入 補丁版本的提交，視情況合入主分支