Git代碼管理規(guī)范

第第頁(yè)Git代碼管理規(guī)范分支命名

master分支

master為主分支，也是用于部署生產(chǎn)環(huán)境的分支，需要確保master分支穩(wěn)定性。master分支一般由release以及ho（tf）ix分支合并，任何時(shí)間都不能直接修改代碼。

develop分支

develop為開(kāi)發(fā)環(huán)境分支，始終保持（最新）完成以及bug修復(fù)后的代碼，用于前后端聯(lián)調(diào)。一般開(kāi)發(fā)新功能時(shí)，feature分支都是基于develop分支創(chuàng)建的。

feature分支

開(kāi)發(fā)新功能時(shí)，以develop為基礎(chǔ)創(chuàng)建feature分支。

分支命名時(shí)以

feature/

開(kāi)頭，后面可以加上開(kāi)發(fā)的功能模塊，命名示例：feature/user_module、feature/cart_module。

（te）st分支

test為測(cè)試環(huán)境分支，外部用戶無(wú)法訪問(wèn)，專門給測(cè)試人員使用，版本相對(duì)穩(wěn)定。

release分支

release為預(yù)上線分支（預(yù)發(fā)布分支），UAT測(cè)試階段使用。一般由test或hotfix分支合并，不建議直接在release分支上直接修改代碼。

hotfix分支

線上出現(xiàn)緊急問(wèn)題時(shí)，需要及時(shí)修復(fù)，以master分支為基線，創(chuàng)建hotfix分支。修復(fù)完成后，需要合并到master分支和develop分支。

分支命名以hotfix/

開(kāi)頭的為修復(fù)分支，它的命名規(guī)則與feature分支類似。

分支與環(huán)境對(duì)應(yīng)關(guān)系

在系統(tǒng)開(kāi)發(fā)過(guò)程中常用的環(huán)境：

DEV環(huán)境（Developmentenvironment）：用于（開(kāi)發(fā)者）調(diào)試使用。

FAT環(huán)境（Feature（Ac）ceptanceTestenvironment）：功能驗(yàn)收測(cè)試環(huán)境，用于測(cè)試環(huán)境下的軟件測(cè)試者測(cè)試使用。

UAT環(huán)境（UserAcceptanceTestenvironment）：用戶驗(yàn)收測(cè)試環(huán)境，用于生產(chǎn)環(huán)境下的軟件測(cè)試者測(cè)試使用。

PRO環(huán)境（Produc（ti）onenvironment）：生產(chǎn)環(huán)境。

對(duì)應(yīng)關(guān)系：

分支功能環(huán)境可訪問(wèn)master主分支，穩(wěn)定版本PRO是develop開(kāi)發(fā)分支，（最新版）本DEV是feature開(kāi)發(fā)分支，實(shí)現(xiàn)新特性

否test測(cè)試分支，功能測(cè)試FAT是release預(yù)上線分支，發(fā)布新版本UAT是hotfix緊急修復(fù)分支，修復(fù)線上bug

否分支合并流程規(guī)范

業(yè)界常見(jiàn)的兩大主分支（master、develop）、三個(gè)輔助分支（feature、release、hotfix）的生命周期：

以上生命周期僅作參考，不同開(kāi)發(fā)團(tuán)隊(duì)可能有不同的規(guī)范，可自行靈活定義。

例如我們團(tuán)隊(duì)在開(kāi)發(fā)時(shí)，至少需要保證以下流程：

develop分支和hotfix分支，必須從master分支檢出。

由develop分支合并到test分支。

功能測(cè)試無(wú)誤后，由test分支合并到release分支。

UAT測(cè)試通過(guò)后，由release分支合并到master分支。

對(duì)于工作量小的功能開(kāi)發(fā)（工時(shí)小于1天），可以直接在devolop分支進(jìn)行開(kāi)發(fā)，否則由develop分支檢出feature分支進(jìn)行開(kāi)發(fā)，開(kāi)發(fā)完后合并到develop分支。

GitCommitMessage規(guī)范

GitCommitMessage規(guī)范指提交代碼時(shí)編寫的規(guī)范解釋，編寫良好的CommitMessage可以達(dá)到3個(gè)重要的目的：

加快代碼review的流程。

幫助我們編寫良好的版本發(fā)布日志。

讓之后的維護(hù)者了解代碼里出現(xiàn)特定變化和feature被添加的原因。

AngularGitCommitGuidelines

業(yè)界應(yīng)用的比較廣泛的是AngularGitCommitGuidelines：

():

type：提交類型。

scope：可選項(xiàng)，本次commit波及的范圍。

（sub）ject：簡(jiǎn)明扼要地闡述下本次commit的主旨，在AngularGitCommitGuidelines中強(qiáng)調(diào)了三點(diǎn)。使用祈使句，首字母不要大寫，結(jié)尾無(wú)需添加標(biāo)點(diǎn)。

body：同樣使用祈使句，在主體內(nèi)容中我們需要把本次commit詳細(xì)地描述一下，比如此次變更的動(dòng)機(jī)。

footer：描述下與之關(guān)聯(lián)的issue或breakchange。

簡(jiǎn)易版

項(xiàng)目中實(shí)際可以采用簡(jiǎn)易版規(guī)范：

():

type規(guī)范

AngularGitCommitGuidelines中推薦的type類型如下：

feat：新增功能。

fix：修復(fù)bug。

docs：僅文檔更改。

style：不影響代碼含義的更改（空白、格式設(shè)置、缺失分號(hào)等）。

refactor：既不修復(fù)bug也不添加特性的代碼更改。

pe（rf）：改進(jìn)性能的代碼更改。

test：添加缺少的測(cè)試或更正現(xiàn)有測(cè)試。

chore：對(duì)構(gòu)建過(guò)程或輔助工具和庫(kù)（如文檔）的更改。

除此之外，還有一些常用的類型：

delete：刪除功能或文件。

modify：修改功能。

build：改變構(gòu)建流程，新增依賴庫(kù)、工具等（例如webpack、gulp、npm修改）。

test：測(cè)試用例的新增、修改。

ci：自動(dòng)化流程配置修改。

revert：回滾到上一個(gè)版本。

單次提交注意事項(xiàng)

提交問(wèn)題必須為同一類別。

提交問(wèn)題不要超過(guò)3個(gè)。

提交的commit發(fā)現(xiàn)不符合規(guī)范，gitcommit--amend-m"新的提交（信息）"或

gitreset--hardHE（AD）

重新提交一次。

配置.gitignore文件

.gitignore是一份用于忽略不必提交的文件的列表，項(xiàng)目中可以根據(jù)實(shí)際需求統(tǒng)一.gitignore文件，減少不必要的文件提交和沖突，凈化代碼庫(kù)環(huán)境。

通用文件示例：

HELP.mdtarget/!.mvn/wrapper/maven-wrapper.jar!**/src/main/**/target/!**/src/test/**/target/###STS###.apt_generated.classpath.fact（or）ject.settings.springBeans.sts4-cache###（Intel）liJIDEA###.idea*.iws*.iml*.ipr###NetBeans###/nbproject/private//nbbuild//dist//nbdist//.nb-gradle/build/!**/src/main/**/build/!**/src/test/**/build/###VSCode###.vscode/#Logfile*.log/logs*#BlueJfiles*.ctxt#MobileToolsfor（Java）(J2ME).mtj.tmp/#PackageFiles#*.jar*.war*.ear*.zip*.tar.gz*.rar*.cmd

其他