常用分支

首先分享一下我們的分支規范，然后再介紹摸索出的打tag的規范。

master

• master : 主分支 , 最終在master分支對外發布，
• 此分支只能從其他分支合并，不能再這個分支直接修改
• 另外所有在master分支的推送應該打標簽做記錄,方便追溯
• 例如release合并到master

develop

• 主測試分支 , 基于master分支創建
• 包含所有要發布到下一個版本的代碼
• 只能從其他分支合并
• release 分支開發完成合并到develop

release

• 開發分支, 基于master分支創建
• 主要用于新需求新功能的開發
• 功能開發完畢后合到develop分支發布測試環境，測試通過后合并到master發布生產環境
• release可同時存在多個

hotfix

• 補丁分支 , 基于master分支創建
• 主要用于對線上的版本進行BUG修復
• 修復完畢后合并到develop分支發布測試環境，測試通過后合并到master發布生產環境
• 屬于臨時分支 , 補丁修復上線后可選刪除

使用

• 初始化項目 , 默認創建master分支
• 從master拉取第一個develop分支
• 從master拉取第一個release分支(多個開發人員拉取多個release同時進行并行開發 , 互不影響)
• release分支完成后 , 合并到develop
• 從develop分支打tag進行提測，提測過程中在原release分支修改BUG，重復步驟4
• 測試通過后合并release到master，基于master分支打tag發布生產環境.此時可刪除當前release分支
• 上線之后若發現線上BUG , 從master拉取hotfix進行BUG修改
• hotfix通過測試上線后可選刪除當前hotfix

注意

• 發布線上時一定是master合并開發分支，develop分支可能存在其它未測試通過代碼
• 兩個分支進行合并時一定要拉取一下最新代碼

tag規范

打tag場景

• 在測試同學線上回歸測試之后一定要給master分支添加tag，方便后續有需求時快速回滾到指定的穩定版本
• 當一個代碼庫在同一個時間段有多個需求要按順序上線時，運維同學需要通過tag標記區分要構建的代碼，這時候需要添加tag。

tag命名規范

版本類型_版本號

比如：stable_v1.1.0

意為：穩定版v1.1.0

版本類型說明

• pre類型的tag應該在測試同學回歸測試通過，打完stable類型或者hotfix類型的tag之后刪除。
• 代碼倉庫只保留stable類型和hotfix類型的tag，方便回滾到穩定版本；不保留pre這種過渡類型的tag。

版本號設置規范

比如版本號：v1.0.0

• 第一個數字1，代表大版本，默認從1開始，大版本更新時才遞增
• 第二個數字0，代表小版本更新，默認從0開始
• 第三個數字0，代表補丁版本，默認從0開始

場景舉例

注意:在打tag的時候需要設置message，寫清楚注釋。

新需求

• tag name命名規范：stable_v1.0.0
• tag message：云倉商品添加銷量字段

修復bug

• tag name 命名規范：hotfix_v1.0.1
• tag message：修復XXX bug

重大版本更新

• tag name 命名規范：stable_v2.0.0
• tag message：項目整體重構后上線

特殊情況

預發布環境，需要按順序構建的：

• tag name 命名規范：pre_v1.0.1
• tag message：預發布tag：商品中心上線
• tag name 命名規范：pre_v1.0.2
• tag message：預發布tag：新渠道上線