分支命名

master 分支

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

develop 分支

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

feature 分支

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

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

test 分支

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

release 分支

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

hotfix 分支

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

分支命名以hotfix/?開頭的為修復(fù)分支，它的命名規(guī)則與 feature 分支類似。

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

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

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

FAT 環(huán)境（Feature Acceptance Test environment）：功能驗收測試環(huán)境，用于測試環(huán)境下的軟件測試者測試使用。

UAT 環(huán)境 （User Acceptance Test environment）：用戶驗收測試環(huán)境，用于生產(chǎn)環(huán)境下的軟件測試者測試使用。

PRO 環(huán)境（Production environment）：生產(chǎn)環(huán)境。

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

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

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

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

例如我們團隊在開發(fā)時，至少需要保證以下流程：

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

由 develop 分支合并到 test 分支。

功能測試無誤后，由 test 分支合并到 release 分支。

UAT 測試通過后，由 release 分支合并到 master 分支。

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

Git Commit Message 規(guī)范

Git Commit Message 規(guī)范指提交代碼時編寫的規(guī)范注釋，編寫良好的 Commit Message 可以達(dá)到 3 個重要的目的：

加快代碼 review 的流程。

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

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

Angular Git Commit Guidelines

業(yè)界應(yīng)用的比較廣泛的是 Angular Git Commit Guidelines：

?

():?

?

type：提交類型。

scope：可選項，本次 commit 波及的范圍。

subject：簡明扼要地闡述下本次 commit 的主旨，在Angular Git Commit Guidelines中強調(diào)了三點。使用祈使句，首字母不要大寫，結(jié)尾無需添加標(biāo)點。

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

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

簡易版

項目中實際可以采用簡易版規(guī)范：

?

():

?

type 規(guī)范

Angular Git Commit Guidelines中推薦的 type 類型如下：

feat：新增功能。

fix：修復(fù) bug。

docs：僅文檔更改。

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

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

perf：改進性能的代碼更改。

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

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

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

delete：刪除功能或文件。

modify：修改功能。

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

test：測試用例的新增、修改。

ci：自動化流程配置修改。

revert：回滾到上一個版本。

單次提交注意事項

提交問題必須為同一類別。

提交問題不要超過 3 個。

提交的 commit 發(fā)現(xiàn)不符合規(guī)范，git commit --amend -m "新的提交信息"或?git reset --hard HEAD?重新提交一次。

配置 .gitignore 文件

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

通用文件示例：

?

HELP.md
target/
!.mvn/wrapper/maven-wrapper.jar
!**/src/main/**/target/
!**/src/test/**/target/

### STS ###
.apt_generated
.classpath
.factorypath
.project
.settings
.springBeans
.sts4-cache

### IntelliJ IDEA ###
.idea
*.iws
*.iml
*.ipr

### NetBeans ###
/nbproject/private/
/nbbuild/
/dist/
/nbdist/
/.nb-gradle/
build/
!**/src/main/**/build/
!**/src/test/**/build/

### VS Code ###
.vscode/

# Log file
*.log
/logs*

# BlueJ files
*.ctxt

# Mobile Tools for Java (J2ME)
.mtj.tmp/

# Package Files #
*.jar
*.war
*.ear
*.zip
*.tar.gz
*.rar
*.cmd

?

其他

此外，還有一些其他建議：

master 分支的每一次更新，都建議打 tag 添加標(biāo)簽，通常為對應(yīng)版本號，便于管理。

feature 分支、hotfix 分支在合并后可以刪除，避免分支過多，管理混亂。

每次 pull 代碼前，提交本地代碼到本地庫中，否則可能會出現(xiàn)合并代碼出錯，導(dǎo)致代碼丟失。

　　審核編輯：湯梓紅