目的

俗話說：沒有規矩，不成方圓。遵循一個好的規章制度能讓你的工作事半功倍。同時也可以展現出你做事的認真的態度以及你的專業性，不會顯得雜亂無章，管理困難。Git分支規范也是一樣。當遵循了某種約定的Git分支，在代碼提交以及多開發、多分支協同工作的時候，必須遵循這個規范操作，否則不予以提交、合并代碼、提測、上線等操作。

適用范圍

適用Git管理開發的所有項目

---

分支約定

Git Flow有主分支和輔助分支兩類分支，通常主分支也被稱為長期分支。

• 主分支用于組織與軟件開發、部署相關的活動；

• 輔助分支組織為了解決特定的問題而進行的各種活動。

主分支是所有開發活動的核心分支。所有的開發活動產生的輸出物最終都會反映到主分支的代碼中。

分支介紹

?????tag：

使用release發布生產成功后，三日之內把release分支合并到master上并打tag。

使用realase分支創建tag版本，使用tag進行線上部署

生產流水線自動打tag

?????master分支：

不接受commit，只接受來自realase分支的merge操作

分支必須開啟分支保護，只有維護者可以操作

?????release分支：

可從test/master分支上拉取；

不接受commit，只接受來自對應test分支的合并操作；

普通開發人員不具有合并權限，需要管理員才能合并

release分支用于發布預生產環境部署；

上線成功后必須立即合并到master

release分支用于發布生產環境部署，上線完成后，禁止合并；

?????test分支

從master/develop分支拉取，用于測試環境部署

不接受commit提交，只接受來自對應develop的合并

?????develop分支：

從master/feature分支拉取，用于開發環境部署

不接受commit提交，只接受來自feature的合并

?????feature分支：

不限制從什么分支拉取，拉取代碼時候版本號必須大于等于最新master的版本

可直接commit

一般不用于任何環境部署，特殊情況可以用于開發環境部署

禁止用于測試、預生產、灰度、生產部署

bug修復分支，也按feature分支規范和流程

?????hotfix分支

緊急bug修復分支，僅用于緊急的線上問題修復，普通bug修復還是使用feature分支規范

分支命名規則及對應環境

分支	命名規則	名稱	環境	權限
master	master	主分支，保護分支，只接受merge?	-	保護
tag	?tag-{上線時間}-v{版本號}?	tag?如：tag-20220803-v1.2.0	-	只讀
release	release-{時間}-{版本號}-{創建人}?；	?預上線分支；release-20220803-v1.2.0-liuyy?	預生產、生產	保護
test	test-{時間}-{功能描述}-{創建人} ；除了前綴，名稱與develop一致	測試部署分支； test-20220803-superChargeV1-liuyy	測試	保護
develop	develop-{時間}-{功能描述}-{創建人}? ； 除了前綴，名稱與feature一致	開發部署分支；develop-20220803-superChargeV1-liuyy	開發	常規
feature	?feature-{創建時間}-{功能描述}-{創建人}?	功能開發分支；feature-20220803-superChargeV1-liuyy	-	常規
hotfix	hotfix-{創建時間}-{bug描述}-{創建人}	緊急bug修復分支；hotfix-20220803-bugxxx-liuyy	不限	常規

分支規則正則：

--javascripttypescriptbashsqljsonhtmlcssccppjavarubypythongorustmarkdown

^(test|feature|develop|hotfix)-(20\d{6})(-\w+){2}$|^(release|tag)-(20\d{6})-v\d+(\.\d+){2}(-\w+){0,1}$

分支使用示意圖

總結

1、一個上線需求一個feature分支，正常情況feature、develop、test、release分支是一一對應的

2、如果有多個需求需要合并上線，那么需要從develop分支開始合并，即多個feature對一個develop分支，但develop、test、release也還是一一對應的

3、除了feature分支外，所有分支都不接受commit，只接受合并

4、普通bug修復使用feature分支，流程一樣

5、緊急bug修復走hotfix分支流程

6、所有上線的代碼必須走完完整的develop、test、release流程

代碼提交規范

• 所有commit必須有注釋，內容必須簡潔明了的描述本次commit涵蓋了哪些內容。嚴禁注釋內容過于簡單或不能明確表達提交內容的！

• 合理控制提交內容的顆粒度，一次commit含一個獨立功能點。嚴禁一次提交涵蓋多個功能項。

• 提交注釋字符數務必大于8, 盡量控制在60個字符之內。

建議參考規范：

示例：

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

type(可選）表示動作類型，可分為：

• fix：修復 xxx Bug

• feat：新增 xxx 功能

• test：調試 xxx 功能

• style：變更 xxx 代碼格式或注釋

• docs：變更 xxx 文檔

• refactor：重構 xxx 功能或方法

scope(可選）?表示影響范圍，可分為：模塊、類庫、方法等。

subject(必須)?表示簡短描述，大于8個字符，小于 60 個字，如果有編號的 Jira 號，建議在描述中加上。