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