Git commit message規範：讓團隊協作更高效

在日常開發中，我們經常會用Git進行版本控制。每次提交代碼時，寫一個清晰的提交信息（commit message）其實非常重要。但很多初學者可能覺得”隨便寫幾句就行”，但實際上，不規範的提交信息會給團隊協作帶來很多麻煩。

爲什麼需要規範的commit message？¶

想象一下：

團隊裏有10個人，如果每個人的提交信息都寫得很隨意（比如“改了點東西”、“修復一下”），過兩週後你想知道某個bug是誰提交的，卻發現所有提交都一樣，根本沒法追蹤。
如果你需要向別人解釋這個項目的更新歷史，比如“這是一個大版本升級”，但提交信息全是零散的改動，根本理不清邏輯。

規範的commit message就像給每一次代碼提交寫一個“說明書”，讓團隊成員能快速理解這次提交做了什麼，方便協作、問題追蹤和版本管理。

規範的commit message長什麼樣？¶

目前最流行的規範是Conventional Commits（約定式提交），它基於Angular項目的提交規範，已經成爲行業標準。簡單來說，規範的commit message可以分爲幾個部分：

<類型>[可選作用域]: <簡短描述>

[可選正文（詳細說明）]

[可選腳註（關聯Issue或破壞性變更）]

1. 類型（Type）：說明提交的性質¶

類型是必填的，它告訴別人這次提交是“新功能”、“修復bug”還是“改文檔”等。常見類型有：

feat：新功能（Feature），比如添加一個按鈕、新接口等。
fix：修復bug，比如修復某個頁面顯示錯誤。
docs：文檔相關，比如更新README或註釋。
style：格式調整（不影響代碼邏輯），比如改縮進、加空格。
refactor：重構代碼（既不是新功能也不是修復bug），比如優化函數結構。
test：添加或修改測試代碼。
chore：瑣事，比如更新依賴、修改構建腳本。

例子：
feat(用戶模塊): 添加登錄驗證碼功能

2. 作用域（Scope）：可選，限定提交的範圍¶

作用域是可選的，用來指明提交影響的代碼模塊或功能範圍。比如項目裏有“用戶模塊”、“購物車模塊”、“支付模塊”等，加上作用域能更精準定位。

例子：
fix(購物車): 解決結算時商品數量爲0的報錯

3. 描述（Description）：簡短說明提交內容¶

描述是必填的，要簡潔明瞭，說明這次提交做了什麼。通常用祈使句，比如“添加”、“修復”、“優化”等。

例子：
feat(用戶模塊): 添加登錄驗證碼功能
（描述部分直接說“添加登錄驗證碼功能”）

4. 正文（Body）：詳細說明（可選）¶

如果描述不夠，正文可以詳細解釋提交的目的、原因或實現方式。比如爲什麼要做這個改動，解決了什麼問題。

例子：

feat(用戶模塊): 添加登錄驗證碼功能

之前的登錄邏輯只有密碼，容易被暴力破解。現在添加了短信驗證碼和郵箱驗證碼兩種方式，提高安全性。

5. 腳註（Footer）：關聯Issue或破壞性變更（可選）¶

腳註可以用來關聯項目的Issue（比如修復了哪個問題），或者說明破壞性變更（Breaking Change）。

破壞性變更：如果提交會影響現有代碼邏輯（比如API接口參數變化），需要在腳註中說明。
關聯Issue：比如 Closes #123 表示這個提交解決了#123號Issue。

例子：

fix(用戶模塊): 修復登錄失敗導致的無限循環

當用戶連續輸錯密碼時，系統沒有限制嘗試次數，導致死循環。現在添加了5次失敗後鎖定賬號的邏輯。

Closes #456

規範的commit message模板和示例¶

模板格式：¶

<type>[可選作用域]: <簡短描述>

[可選正文]

[可選腳註]

示例1：新功能（feat）¶

feat(支付): 添加微信支付功能

支持用戶使用微信掃碼支付，提高支付渠道。

Closes #78

示例2：修復bug（fix）¶

fix(購物車): 解決結算時商品重複計算的問題

之前用戶多次添加同一商品時，結算金額會重複累加。現在修復了數量計算邏輯，確保每個商品只算一次。

Fixes #123

示例3：破壞性變更（Breaking Change）¶

feat(api): 新增用戶查詢接口

新增了 /api/user/list 接口，但舊接口 /api/users 已廢棄，調用方需升級到新接口。

BREAKING CHANGE: 廢棄舊接口 /api/users，新接口返回格式調整爲...

如何養成規範寫commit message的習慣？¶

1. 記住常用類型¶

feat（新功能）、fix（修復）、docs（文檔）、chore（瑣事）是最常用的。

2. 使用工具輔助¶

commitizen：交互式命令行工具，讓你一步步選擇類型、作用域和描述，避免手動寫規範。
安裝：npm install -g commitizen
使用：git cz 代替 git commit，跟着提示填寫。
commitlint + husky：自動檢查提交信息是否符合規範，提交前攔截不符合規範的信息。

規範帶來的好處¶

團隊協作更高效：成員能快速理解提交內容，不用翻代碼就能知道這次改了啥。
自動生成版本日誌：工具（如standard-version）能根據commit message自動生成ChangeLog，直接對應版本更新內容。
問題追蹤更清晰：通過 Closes #123 直接關聯Issue，提交和問題一一對應。
破壞性變更提前預警：破壞性變更明確標註，避免影響其他模塊。

總結¶

規範的commit message不是強制要求，但養成這個習慣能極大提升團隊協作效率。記住核心原則：類型+描述+必要細節，寫清楚“這次提交是幹嘛的，爲什麼這麼做”。剛開始可能需要刻意練習，但熟練後會發現好處遠超投入的時間。

現在，下次提交代碼時，試着用規範的格式寫一條信息吧！