目的

俗話說(shuō)：沒(méi)有規(guī)矩，不成方圓。遵循一個(gè)好的規(guī)章制度能讓你的工作事半功倍。同時(shí)也可以展現(xiàn)出你做事的認(rèn)真的態(tài)度以及你的專業(yè)性，不會(huì)顯得雜亂無(wú)章，管理困難。Git分支規(guī)范也是一樣。當(dāng)遵循了某種約定的Git分支，在代碼提交以及多開(kāi)發(fā)、多分支協(xié)同工作的時(shí)候，必須遵循這個(gè)規(guī)范操作，否則不予以提交、合并代碼、提測(cè)、上線等操作。

適用范圍

適用Git管理開(kāi)發(fā)的所有項(xiàng)目

---

分支約定

Git Flow有主分支和輔助分支兩類(lèi)分支，通常主分支也被稱為長(zhǎng)期分支。

• 主分支用于組織與軟件開(kāi)發(fā)、部署相關(guān)的活動(dòng)；

• 輔助分支組織為了解決特定的問(wèn)題而進(jìn)行的各種活動(dòng)。

主分支是所有開(kāi)發(fā)活動(dòng)的核心分支。所有的開(kāi)發(fā)活動(dòng)產(chǎn)生的輸出物最終都會(huì)反映到主分支的代碼中。

分支介紹

?????tag：

使用release發(fā)布生產(chǎn)成功后，三日之內(nèi)把release分支合并到master上并打tag。

使用realase分支創(chuàng)建tag版本，使用tag進(jìn)行線上部署

生產(chǎn)流水線自動(dòng)打tag

?????master分支：

不接受commit，只接受來(lái)自realase分支的merge操作

分支必須開(kāi)啟分支保護(hù)，只有維護(hù)者可以操作

?????release分支：

可從test/master分支上拉取；

不接受commit，只接受來(lái)自對(duì)應(yīng)test分支的合并操作；

普通開(kāi)發(fā)人員不具有合并權(quán)限，需要管理員才能合并

release分支用于發(fā)布預(yù)生產(chǎn)環(huán)境部署；

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

release分支用于發(fā)布生產(chǎn)環(huán)境部署，上線完成后，禁止合并；

?????test分支

從master/develop分支拉取，用于測(cè)試環(huán)境部署

不接受commit提交，只接受來(lái)自對(duì)應(yīng)develop的合并

?????develop分支：

從master/feature分支拉取，用于開(kāi)發(fā)環(huán)境部署

不接受commit提交，只接受來(lái)自feature的合并

?????feature分支：

不限制從什么分支拉取，拉取代碼時(shí)候版本號(hào)必須大于等于最新master的版本

可直接commit

一般不用于任何環(huán)境部署，特殊情況可以用于開(kāi)發(fā)環(huán)境部署

禁止用于測(cè)試、預(yù)生產(chǎn)、灰度、生產(chǎn)部署

bug修復(fù)分支，也按feature分支規(guī)范和流程

?????hotfix分支

緊急bug修復(fù)分支，僅用于緊急的線上問(wèn)題修復(fù)，普通bug修復(fù)還是使用feature分支規(guī)范

分支命名規(guī)則及對(duì)應(yīng)環(huán)境

分支	命名規(guī)則	名稱	環(huán)境	權(quán)限
master	master	主分支，保護(hù)分支，只接受merge?	-	保護(hù)
tag	?tag-{上線時(shí)間}-v{版本號(hào)}?	tag?如：tag-20220803-v1.2.0	-	只讀
release	release-{時(shí)間}-{版本號(hào)}-{創(chuàng)建人}?；	?預(yù)上線分支；release-20220803-v1.2.0-liuyy?	預(yù)生產(chǎn)、生產(chǎn)	保護(hù)
test	test-{時(shí)間}-{功能描述}-{創(chuàng)建人} ；除了前綴，名稱與develop一致	測(cè)試部署分支； test-20220803-superChargeV1-liuyy	測(cè)試	保護(hù)
develop	develop-{時(shí)間}-{功能描述}-{創(chuàng)建人}? ； 除了前綴，名稱與feature一致	開(kāi)發(fā)部署分支；develop-20220803-superChargeV1-liuyy	開(kāi)發(fā)	常規(guī)
feature	?feature-{創(chuàng)建時(shí)間}-{功能描述}-{創(chuàng)建人}?	功能開(kāi)發(fā)分支；feature-20220803-superChargeV1-liuyy	-	常規(guī)
hotfix	hotfix-{創(chuàng)建時(shí)間}-{bug描述}-{創(chuàng)建人}	緊急bug修復(fù)分支；hotfix-20220803-bugxxx-liuyy	不限	常規(guī)

分支規(guī)則正則：

--javascripttypescriptbashsqljsonhtmlcssccppjavarubypythongorustmarkdown

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

分支使用示意圖

總結(jié)

1、一個(gè)上線需求一個(gè)feature分支，正常情況feature、develop、test、release分支是一一對(duì)應(yīng)的

2、如果有多個(gè)需求需要合并上線，那么需要從develop分支開(kāi)始合并，即多個(gè)feature對(duì)一個(gè)develop分支，但develop、test、release也還是一一對(duì)應(yīng)的

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

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

5、緊急bug修復(fù)走h(yuǎn)otfix分支流程

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

代碼提交規(guī)范

• 所有commit必須有注釋，內(nèi)容必須簡(jiǎn)潔明了的描述本次commit涵蓋了哪些內(nèi)容。嚴(yán)禁注釋內(nèi)容過(guò)于簡(jiǎn)單或不能明確表達(dá)提交內(nèi)容的！

• 合理控制提交內(nèi)容的顆粒度，一次commit含一個(gè)獨(dú)立功能點(diǎn)。嚴(yán)禁一次提交涵蓋多個(gè)功能項(xiàng)。

• 提交注釋字符數(shù)務(wù)必大于8, 盡量控制在60個(gè)字符之內(nèi)。

建議參考規(guī)范：

示例：

fix(首頁(yè)模塊)：修復(fù)彈窗 JS Bug。

type(可選）表示動(dòng)作類(lèi)型，可分為：

• fix：修復(fù) xxx Bug

• feat：新增 xxx 功能

• test：調(diào)試 xxx 功能

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

• docs：變更 xxx 文檔

• refactor：重構(gòu) xxx 功能或方法

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

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