分支命名

master 分支

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

develop 分支

develop 為開發環境分支，始終保持最新完成以及 bug 修復后的代碼，用于前后端聯調。一般開發新功能時，feature 分支都是基于 develop 分支創建的。

feature 分支

開發新功能時，以 develop 為基礎創建 feature 分支。

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

test 分支

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

release 分支

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

hotfix 分支

線上出現緊急問題時，需要及時修復，以 master 分支為基線，創建 hotfix 分支。修復完成后，需要合并到 master 分支和 develop 分支。

分支命名以hotfix/?開頭的為修復分支，它的命名規則與 feature 分支類似。

分支與環境對應關系

在系統開發過程中常用的環境：

DEV 環境（Development environment）：用于開發者調試使用。

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

UAT 環境 （User Acceptance Test environment）：用戶驗收測試環境，用于生產環境下的軟件測試者測試使用。

PRO 環境（Production environment）：生產環境。

對應關系：

分支合并流程規范

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

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

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

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

由 develop 分支合并到 test 分支。

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

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

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

Git Commit Message 規范

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

加快代碼 review 的流程。

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

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

Angular Git Commit Guidelines

業界應用的比較廣泛的是 Angular Git Commit Guidelines：

?

():?

?

type：提交類型。

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

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

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

footer：描述下與之關聯的 issue 或 break change。

簡易版

項目中實際可以采用簡易版規范：

?

():

?

type 規范

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

feat：新增功能。

fix：修復 bug。

docs：僅文檔更改。

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

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

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

test：添加缺少的測試或更正現有測試。

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

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

delete：刪除功能或文件。

modify：修改功能。

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

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

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

revert：回滾到上一個版本。

單次提交注意事項

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

提交問題不要超過 3 個。

提交的 commit 發現不符合規范，git commit --amend -m "新的提交信息"或?git reset --hard HEAD?重新提交一次。

配置 .gitignore 文件

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

通用文件示例：

?

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 添加標簽，通常為對應版本號，便于管理。

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

每次 pull 代碼前，提交本地代碼到本地庫中，否則可能會出現合并代碼出錯，導致代碼丟失。

　　審核編輯：湯梓紅