分支命名
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主分支,穩定版本PRO是develop開發分支,最新版本DEV是feature開發分支,實作新特性
否test測試分支,功能測試FAT是release預上線分支,釋出新版本UAT是hotfix緊急修複分支,修複線上bug
否
分支合并流程規範
業界常見的兩大主分支(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 messages可以達到3個重要的目的:
- 加快代碼review的流程
- 幫助我們編寫良好的版本釋出日志
- 讓之後的維護者了解代碼裡出現特定變化和feature被添加的原因
Angular Git Commit Guidelines
業界應用的比較廣泛的是Angular Git Commit Guidelines:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
- type:送出類型
- scope:可選項,本次 commit 波及的範圍
- subject:簡明扼要的闡述下本次 commit 的主旨,在Angular Git Commit Guidelines中強調了三點。使用祈使句,首字母不要大寫,結尾無需添加标點
- body: 同樣使用祈使句,在主體内容中我們需要把本次 commit 詳細的描述一下,比如此次變更的動機
- footer: 描述下與之關聯的 issue 或 break change
簡易版
項目中實際可以采用簡易版規範:
<type>(<scope>):<subject>
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 代碼前,送出本地代碼到本地庫中,否則可能回出現合并代碼出錯,導緻代碼丢失