git分支tag怎麼理解-tft每日頭條

git分支tag怎麼理解?首先分享一下我們的分支規範，然後再介紹摸索出的打tag的規範，我來為大家科普一下關于git分支tag怎麼理解?下面希望有你要的答案，我們一起來看看吧!

git分支tag怎麼理解

分支規範

首先分享一下我們的分支規範，然後再介紹摸索出的打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：新渠道上線希望分享的知識都可以幫助到大家，也希望大家學了都有收獲！