Git 分支設計規範

時間 2020-03-06

標籤 git 分支設計規範欄目 Git 简体版

原文原文鏈接

概述

這篇文章分享 Git 分支設計規範，目的是提供給研發人員作參考。git

規範是死的，人是活的，但願本身定的規範，不要被打臉。測試

在說 Git 分支規範以前，先說下在系統開發過程當中經常使用的環境。設計

簡稱	全稱
DEV	Development environment
FAT	Feature Acceptance Test environment
UAT	User Acceptance Test environment
PRO	Production environment

DEV 環境：用於開發者調試使用。
FAT 環境：功能驗收測試環境，用於測試環境下的軟件測試者測試使用。
UAT 環境：用戶驗收測試環境，用於生產環境下的軟件測試者測試使用。
PRO 環境：就是生產環境。

好比，項目域名爲：http://www.abc.com，那麼相關環境的域名可這樣配置：調試

DEV 環境：本地配置虛擬域名便可
FAT 環境：http://fat.abc.com
UAT 環境：http://uat.abc.com
PRO 環境：http://www.abc.com

接下來，針對不一樣的環境來設計分支。日誌

分支

分支	名稱	環境	可訪問
master	主分支	PRO	是
release	預上線分支	UAT	是
hotfix	緊急修復分支	DEV	否
develop	測試分支	FAT	是
feature	需求開發分支	DEV	否

master 分支

master 爲主分支，用於部署到正式環境（PRO），通常由 release 或 hotfix 分支合併，任何狀況下不容許直接在 master 分支上修改代碼。code

release 分支

release 爲預上線分支，用於部署到預上線環境（UAT），始終保持與 master 分支一致，通常由 develop 或 hotfix 分支合併，不建議直接在 release 分支上直接修改代碼。接口

若是在 release 分支測試出問題，須要迴歸驗證 develop 分支看否存在此問題。開發

hotfix 分支

hotfix 爲緊急修復分支，命名規則爲 hotfix- 開頭。文檔

當線上出現緊急問題須要立刻修復時，須要基於 release 或 master 分支建立 hotfix 分支，修復完成後，再合併到 release 或 develop 分支，一旦修復上線，便將其刪除。部署

develop 分支

develop 爲測試分支，用於部署到測試環境（FAT），始終保持最新完成以及 bug 修復後的代碼，可根據需求大小程度肯定是由 feature 分支合併，仍是直接在上面開發。

必定是知足測試的代碼才能往上面合併或提交。

feature 分支

feature 爲需求開發分支，命名規則爲 feature- 開頭，一旦該需求上線，便將其刪除。

這麼說可能有點不容易理解，接下來舉幾個開發場景。

開發場景

新需求加入

有一個訂單管理的新需求須要開發，首先要建立一個 feature-order 分支，問題來了，該分支是基於哪一個分支建立？

若是存在未測試完畢的需求，就基於 master 建立。

若是不存在未測試完畢的需求，就基於 develop 建立。

需求在 feature-order 分支開發完畢，準備提測時，要先肯定 develop 不存在未測試完畢的需求，這時研發人員才能將將代碼合併到 develop （測試環境）供測試人員測試。
測試人員在 develop （測試環境）測試經過後，研發人員再將代碼發佈到 release （預上線環境）供測試人員測試。
測試人員在 release （預上線環境）測試經過後，研發人員再將代碼發佈到 master （正式環境）供測試人員測試。
測試人員在 master (正式環境) 測試經過後，研發人員須要刪除 feature-order 分支。

普通迭代

有一個訂單管理的迭代需求，若是開發工時 < 1d，直接在 develop 開發，若是開發工時 > 1d，那就須要建立分支，在分支上開發。

開發後的提測上線流程與新需求加入的流程一致。

修復測試環境 Bug

在 develop 測試出現了Bug，若是修復工時 < 2h，直接在 develop 修復，若是修復工時 > 2h，須要在分支上修復。

修復後的提測上線流程與新需求加入的流程一致。

修改預上線環境 Bug

在 release 測試出現了Bug，首先要回歸下 develop 分支是否一樣存在這個問題。

若是存在，修復流程與修復測試環境 Bug流程一致。

若是不存在，這種可能性比較少，大部分是數據兼容問題，環境配置問題等。

修改正式環境 Bug

在 master 測試出現了Bug，首先要回歸下 release 和 develop 分支是否一樣存在這個問題。

若是存在，修復流程與修復測試環境 Bug流程一致。

若是不存在，這種可能性也比較少，大部分是數據兼容問題，環境配置問題等。

緊急修復正式環境 Bug

需求在測試環節未測試出 Bug，上線運行一段時候後出現了 Bug，須要緊急修復的。

我我的理解緊急修復的意思是沒時間驗證測試環境了，但仍是建議驗證下預上線環境。

若是 release 分支存在未測試完畢的需求，就基於 master 建立 hotfix-xxx 分支，修復完畢後發佈到 master 驗證，驗證完畢後，將 master 代碼合併到 release 和 develop 分支，同時刪掉 hotfix-xxx 分支。
若是 release 分支不存在未測試完畢的需求，但 develop 分支存在未測試完畢的需求，就基於 release 建立 hotfix-xxx 分支，修復完畢後發佈到 release 驗證，後面流程與上線流程一致，驗證完畢後，將 master 代碼合併到 develop 分支，同時刪掉 hotfix-xxx 分支。
若是 release 和 develop 分支都不存在未測試完畢的需求，就直接在 develop 分支上修復完畢後，發佈到 release 驗證，後面流程與上線流程一致。

並行提測

在一個項目中並行開發了兩個需求，並行提測，可是上線日期不一樣。

我能想到的兩種方案：

再部署一套可供測試人員測試的分支
使用 git cherry-pick 「挑揀」提交

對於並行提測，你有好的方案嗎？歡迎留言。

Commit 日誌規範

提交信息必定要認真填寫！

建議參考規範：<type>(scope)：<subject>

好比：fix(首頁模塊)：修復彈窗 JS Bug。

type 表示動做類型，可分爲：

fix：修復 xxx Bug
feat：新增 xxx 功能
test：調試 xxx 功能
style：變動 xxx 代碼格式或註釋
docs：變動 xxx 文檔
refactor：重構 xxx 功能或方法

scope 表示影響範圍，可分爲：模塊、類庫、方法等。

subject 表示簡短描述，最好不要超過 60 個字，若是有相關 Bug 的 Jira 號，建議在描述中加上。

小結

暫時就想到這麼多，規範這東西不是一成不變的，供參考。