背景

在項目開發過程中，往往一個優秀的產品都會出現不斷的版本迭代，我時常在項目發布后對于如何結合后續更新的業務場景在分支上的應用沒有一個很好的辦法，一直也比較苦惱。目前項目的迭代場景如下，一個A項目，經過需求分析，產品經理下令開發團隊開發，那么經過數月后成功上線，發布V1.0.0.0. 緊接著我們就會進入第二期開發，產品經理會列出第二期的具體開發內容，隨即我們就開干了……，然后在開發過程中，發布出去的V1.0.0.0反饋出很多問題，有業務的，有緊急的，各種情況的問題….

對于上面的問題，我相信很多人都遇到過，如果是你，你會怎么做呢？我先說一下目前我的做法，首先我放棄了主分支概念，當產品經理說我們第一個版本為V1.0.0.0時，我在git上就創建出了分支V1.0.0.0,我以版本為分支的形式來應對。當進入第二期時，我會根據V1.0.0.0的最新commit來創建出一個新分支V1.0.0.1作為下一個版本的開發分支。如果V1.0.0.0反饋有問題，我會立即切回到V1.0.0.1分支上進行開發，測試，然后tag一個新的標簽出來為V1.0.0.0.1 作為修復版本……，然后將代碼合并到V1.0.0.1上繼續開發。

對于上面這種玩法前期還好，后期有一個重大缺點，因為按照版本號創建的分支，所以后期分支會非常多，難以維護，最終會把自己累死。

優點	缺點
使用 tag 明確版本	分支命名不清晰（既是 1.0.0.0 又包含 1.0.0.1 內容）
tag 打在某個 commit 上是合理的	沒有合并到主分支（main），未來不好維護
便于查看歷史提交	如果多人協作，容易造成混亂
能記錄版本信息	后續修復 bug 不方便追溯

標準版本發布流程

后來基于上面的痛點以及詢問了一些前輩的意見，打算使用如下的一個流程。這是一個 基于 Git 的常見版本管理流程（適用于敏捷開發）：

1.分支結構

分支	用途說明	是否要長期存在
master	主分支，用于生產環境代碼	長期
dev	開發主分支，集成所有功能	長期
release/版本號	準備發布的版本分支(不加新功能)	臨時
hotfix/版本號	緊急修復分支(不加新功能)	臨時

2.版本開發 & 發布流程圖

develop↓ merge → release/4.1.0.1 → 測試團隊測試↓測試通過 → 打 tag v4.1.0.1↓merge 到 main（或直接部署）↓merge 回 develop（帶回 bug 修復）

3.標準流程

3.1 創建release/版本號 分支

先創建出一個分支release/4.1.0.1

3.2 根據產品經理發布的版本進行開發

在dev分支上開發完要求的功能內容

3.3 在release/版本號做最后調整跟測試

• 開發完成的功能合入 release/4.1.0.1

• 修復一些小問題（不能加新功能）

3.4 提交給測試部門測試

• 將release/4.1.0.1分支提交給測試部門測試
• 測試完成后確認沒問題

3.5 合并到主分支

• 合并到master上
• 在最新的commit上打上tag=v4.1.0.1

3.6 合并到開發分支

• 合并到dev上

3.7 刪除release

• 看一下需要，如果不經常再變動，可以先刪掉。后期如果需要，可以再根據tag標記的位置根據實際情況來新建出/release/版本號

4.如果上線后發現 bug 怎么辦？——打 Hotfix

4.1 創建 hotfix 分支

先基于某一個tag:v4.1.0.1上新建一個緊急分支出來hotfix/4.1.0.1-patch1

4.2 修復 bug 并測試通過

• 將hotfix/4.1.0.1-patch1分支提交給測試部門測試
• 測試完成后確認沒問題

4.4 合并master

• 合并到master上
• 在最新的commit上打上tag=v4.1.0.1-patch1

4.5 合并到開發分支

• 合并到dev上

4.5 刪除分支

• 刪除hotfix/4.1.0.1-patch1分支