首頁 > 軟體

Git操作規範之tag的使用技巧詳解

2022-09-08 18:04:39

常用分支

首先分享一下我們的分支規範,然後再介紹摸索出的打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預釋出版,用於運維同學知曉要構建的程式碼上線測試無誤後刪除pre型別的tag
stable穩定版,新功能上線後使用這個型別不刪除tag,方便後續回滾
hotfix修復版,修復線上bug使用這個型別不刪除tag,方便後續回滾
  • 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:新渠道上線

以上就是Git操作規範之tag的使用技巧詳解的詳細內容,更多關於Git tag操作規範的資料請關注it145.com其它相關文章!


IT145.com E-mail:sddin#qq.com