爲什麼需要統一的提交規範？¶
在團隊協作中，每次修改代碼後都要寫Git提交信息（Commit Message）。如果大家提交信息寫得亂七八糟，比如“改了一下”“修了個bug”，會帶來很多問題：
- 代碼審查困難：別人不知道你具體改了什麼，要花時間看代碼才能理解
- 版本迭代混亂：版本歷史看不懂，不知道某次提交是新增功能還是修復問題
- 自動化工具失效：像生成版本日誌、自動關聯Issue等工具可能無法工作
統一的提交規範就像給每次修改“貼標籤”，讓大家一眼就能看懂這次改動的目的和內容。
第一步：理解提交信息的規範格式¶
目前最流行的規範是 Conventional Commits，它把提交信息分成幾個清晰的部分：
<類型>[可選作用域]: <描述>
[可選正文]
[可選腳註]
1. 類型（type）：告訴別人這次提交的“性質”¶
類型必須是以下幾種之一，選錯會誤導版本迭代：
feat：新增功能（比如“添加用戶登錄按鈕”）fix：修復bug（比如“修復購物車結算時金額計算錯誤”）docs：文檔相關（比如“更新API文檔說明”）style：格式調整（不影響代碼邏輯，比如改縮進、空格）refactor：代碼重構（既不是新增也不是修復，比如優化算法）test：添加/修改測試代碼chore：其他雜項（比如改配置文件、依賴版本）
示例：feat: 新增用戶註冊頁面
2. 描述（description）：簡潔說明改動內容¶
- 要簡短（一般不超過50字），但必須清晰
- 以動詞開頭（比如“添加”“修復”“優化”）
- 不能用疑問句或感嘆句，直接陳述事實
錯誤：改了頁面佈局（太模糊）
正確：優化首頁導航欄佈局（明確改了哪裏）
3. 正文（body，可選）：詳細解釋改動細節¶
如果描述不夠清楚，可以用空行隔開正文部分，詳細說明：
- 爲什麼做這個改動
- 具體實現了什麼功能
- 解決了什麼問題
示例：
fix: 修復移動端菜單點擊無反應
- 移動端菜單按鈕綁定的點擊事件未觸發
- 檢查發現是事件委託的選擇器錯誤
- 已修改爲正確的子元素選擇器
4. 腳註（footer，可選）：關聯問題或說明影響¶
- 可以關聯Issue（比如
Closes #123表示修復了編號123的問題） - 如果有破壞性改動（比如API變更），需要用
BREAKING CHANGE:開頭說明
示例：
feat: 添加用戶權限管理功能
- 支持管理員/普通用戶角色區分
- 新增權限校驗中間件
Closes #456 // 關聯開發計劃中的任務
第二步：創建團隊提交模板¶
方法1：全局配置（所有項目通用）¶
- 創建模板文件：在電腦中新建一個文本文件（比如
.gitmessage），放在用戶根目錄（Windows是C:\Users\用戶名，Mac/Linux是~），內容如下：
# 提交信息模板
## 類型（必填）：
- feat: 新增功能
- fix: 修復bug
- docs: 文檔更新
- style: 格式調整
- refactor: 代碼重構
- test: 測試相關
- chore: 其他雜項
## 描述（必填，不超過50字）：
[用動詞開頭描述改動內容，例如：添加用戶註冊功能]
## 正文（可選，多行）：
[詳細說明改動原因、實現細節或測試情況]
## 腳註（可選）：
- 關聯Issue: Closes #編號
- 破壞性改動: BREAKING CHANGE: [說明]
- 配置Git使用模板：打開終端，執行以下命令：
git config --global commit.template ~/.gitmessage
以後每次執行git commit時，Git會自動打開模板文件，方便填寫。
方法2：項目級模板（僅當前項目使用）¶
如果團隊有特定規範，或者項目需要單獨配置，可以在項目根目錄新建.gitmessage文件，內容同上。然後在項目內執行：
git config commit.template .gitmessage
這樣只有當前項目會使用這個模板，避免影響其他項目。
第三步：使用模板提交代碼¶
快速提交（單行信息）¶
如果改動簡單，直接用-m參數寫提交信息：
git commit -m "feat: 修復登錄按鈕樣式"
詳細提交（使用模板）¶
如果改動複雜，會自動打開編輯器（比如Vim），顯示模板內容，按規範填寫即可：
git commit
填寫完後保存退出（Vim中按ESC，輸入:wq回車）。
工具輔助：強制規範提交信息¶
爲了讓團隊成員嚴格遵守規範，推薦使用工具自動檢查：
1. Commitlint：檢查提交信息是否符合規範¶
- 安裝：
npm install --save-dev @commitlint/cli @commitlint/config-conventional - 配置：在項目根目錄新建
commitlint.config.js，內容：
module.exports = {extends: ['@commitlint/config-conventional']}
- 使用：在提交前，Commitlint會自動檢查信息格式，不符合則報錯。
2. Husky：在提交前觸發檢查¶
Husky是Git鉤子工具，能在提交、推送等操作前執行腳本。配合Commitlint，在提交前強制檢查：
- 安裝：npm install husky --save-dev
- 初始化：npx husky install
- 添加鉤子：npx husky add .husky/commit-msg 'npx --no -- commitlint --edit $1'
這樣提交時如果信息不規範，就會被攔截，無法提交。
常見錯誤和注意事項¶
- 類型選錯：比如把
fix寫成chore，導致版本日誌不準確 - 描述太模糊：比如只寫“改了bug”，別人不知道改了哪裏
- 正文冗餘：不需要重複代碼裏已經寫清楚的內容
- 關聯Issue不完整：應該寫
Closes #123而不是隻寫#123
正確示例：
fix: 修復購物車數量計算錯誤
- 當商品數量爲0時，結算按鈕未隱藏
- 檢查發現是條件判斷邏輯錯誤（>=0 應爲 >0）
Closes #789 // 關聯具體問題編號
總結¶
規範的提交信息就像給每次代碼改動寫“說明書”，能讓團隊協作更順暢。記住：類型明確、描述清晰、正文簡潔、腳註關聯，是寫出好提交信息的核心。即使是個人項目，養成規範提交的習慣也能讓自己後續維護代碼更輕鬆。
如果團隊已經用慣了模板，記得把.gitmessage和工具配置（Commitlint/Husky）共享給所有人，一起養成良好的開發習慣！