基本代碼分支應該分為兩類，一類是主要分支，包括線上主分支 Master 和開發主分支
Develop；另一類是輔助分支，包括測試分支 Release，線上緊急修復分支 Hotfix，以及功能
開發分支 Feature。
● Master 分支上的所有代碼節點都必須處於可發布狀態，且與線上運行的版本對應並且每一個
節點都生成了 Tag 標註了發布的版本 ID。
● Develop 分支上的代碼節點代表了最新的功能開發進度，用於日常的功能開發，集成了多個新
開發的功能以及正式提測前的 bug 修復代碼。
● Feature 分支用於管理功能的並行開發（命名建議為”feature-*”） ，起源於 Develop 分支，最終
也會歸於 Develop 分支（要求采用--no-ff 的方式進行分支合並，以確保整個提交鏈的完整
性） 。
● Release 分支主要用於正式的測試並幫助構建可發布的代碼（命名建議為”release-*”） ，起源於
Develop 分支，最終歸於“develop”及“master”分支。正式提測後的 bug 修復必須在此分支上進
行，並且需盡量避免新功能的並入。每次當 Release 代碼合並到 Master 分支時都必須反向合
並回 Develop 分支。
● Hotfix 分支用於緊急修復線上運行版本的關鍵 BUG（命名建議為”hotfix-*”） ，hotfix 分支基於
Master 分支創建，開發完後需要合並回 Master、Release 和 Develop 分支，同時在 Master
上打一個 Tag。

Release 和 Master 分支須受到保護，必須有固定的一到兩名人員負責分支的合並操作。

提測規範
● 持續集成應用接入 QA 環境需根據線上最新版本代碼做一次初始化
● 每次提交代碼都需正確填寫備註（功能描述） ，每次發版都要打 Tag 標簽
● 提測期間有問題，基於 Release 分支修改，測試通過後基於 Release 發布
● 線上緊急 bug從 Master 拉 Hotfix 分支修改，合並至 Master 發版修復
● SA 組除 HotFix 外的發版均基於提測通過的 Release 分支

代碼管理準則
● 創建分支要有計劃性，盡可能的控制分支的數量
● 低版本總是積極的合並到高版本，同時註意反向合並
● 每次提交及合並的日誌須完整規範，說明修改部分的意圖
● 發起合並的版本務必經過冒煙自測及代碼評審
● 珍惜每次提測，提測內容與修改內容相符

Git 基本分支規範