在多人協作的Git項目中，每次提交代碼時寫一個清晰的提交信息（commit message）非常重要。它不僅能幫助團隊成員快速理解這次提交的內容，還能在後續通過工具自動生成版本日誌（比如 standard-version），甚至在排查問題時節省時間。但如果提交信息混亂或不規範，比如“修復bug”“改了點東西”，就很難追溯變更的目的和影響。
Angular風格的提交規範基本格式¶
Angular風格的commit message分爲三部分：Header（標題）、Body（正文）、Footer（頁腳）。其中Header是必須的，Body和Footer可選。整體結構如下：
<type>(<scope>): <subject>
[body]
[footer]
1. Header（標題）：簡潔描述變更核心¶
Header格式爲：type(scope?): subject
- type（類型）：必須從以下列表中選擇，用於明確變更性質：
feat：新功能（feature）fix：修復bugdocs：文檔更新style：格式調整（不影響代碼邏輯，如空格、換行、縮進）refactor：代碼重構（既非新增功能也非修復bug）perf：性能優化test：測試相關（添加/修改測試代碼）-
chore：其他不影響代碼邏輯的變更（如構建腳本、依賴管理） -
scope（範圍，可選）：指定變更影響的模塊或功能區域（如
login、api、home），若不明確可省略。 -
subject（主題）：簡短描述變更內容，需以祈使句開頭（如“Add”而非“Added”），不超過50字符，結尾不加句號。
示例：¶
feat(login): add "Remember Me" option // 類型：新功能，範圍：login模塊，主題：添加“記住我”選項
2. Body（正文）：詳細說明變更細節¶
Body用於補充說明爲什麼做這個變更及具體實現內容，需另起一行，並用空行與Header分隔。可寫多行，每行簡潔描述關鍵點。
示例：¶
feat(login): add "Remember Me" option
- 新增“記住我”複選框，勾選後下次登錄自動填充賬號密碼
- 使用加密存儲token和賬號信息，避免明文泄露
3. Footer（頁腳）：標記特殊信息¶
Footer可選，用於說明不兼容變更（Breaking Changes）或關閉Issue，同樣用空行與Body分隔。
（1）不兼容變更（Breaking Changes）¶
若提交包含破壞性變更（如API接口修改），需在Footer中以BREAKING CHANGE:開頭，明確描述影響範圍。
示例：¶
fix(api): correct user info response format
BREAKING CHANGE: 原 `/api/user/profile` 返回的 `{name: string}` 改爲 `{username: string}`，舊調用方需同步更新。
（2）關閉Issue¶
若本次提交解決了某個Issue，可在Footer中用Closes #Issue編號格式關聯。
示例：¶
fix(checkout): resolve payment timeout bug
Closes #123 // 關閉編號爲123的Issue
完整示例集合¶
以下是不同場景的完整提交信息示例：
示例1：新功能（feat）¶
feat(home): add search component
- 新增頂部搜索欄，支持關鍵詞即時搜索
- 綁定後端接口，返回匹配結果列表
示例2：修復bug（fix）¶
fix(auth): resolve token expiration issue
- 修復token過期後未自動刷新的問題
- 添加本地緩存過期時間檢查，延長token有效期至7天
示例3：帶破壞性變更（BREAKING CHANGE）¶
refactor(api): remove deprecated /v1/user/list endpoint
BREAKING CHANGE: 廢棄 `/v1/user/list` API，所有調用方需遷移至 `/v2/user/list`。
示例4：關閉Issue¶
docs: update contribution guide
Closes #45 // 解決#45號Issue中“文檔缺失”問題
工具輔助規範提交信息¶
手動寫易出錯，推薦使用工具自動生成規範提交信息：
-
Commitizen（cz-cli）：交互式命令行工具，引導填寫規範信息。
安裝：npm install -g commitizen
使用：在項目根目錄執行commitizen init cz-conventional-changelog --save-dev，之後用npm run commit代替git commit，按提示選擇即可生成規範信息。 -
commitlint：校驗提交信息是否符合規範，配合
husky在提交前自動攔截不規範信息。
注意事項¶
- type必須規範：只能用指定類型（如
feat而非“new”）。 - subject簡潔明確：以動詞開頭（如“Add”“Fix”），避免冗餘描述。
- Body按需填寫：簡單變更可省略Body，但複雜邏輯需說明“爲什麼改”。
- Footer的Breaking Changes需明確：破壞性變更必須單獨列出，避免後續開發踩坑。
總結¶
規範的Git提交信息能讓項目協作更高效，幫助團隊快速理解代碼變更，也便於工具自動生成版本日誌。Angular風格是目前最通用的規範，從下一次提交開始，試着用清晰的格式寫commit message吧！養成習慣後，你會發現追溯問題、協作溝通都會更順暢～