Git 提交規范通常是為了提高代碼提交的可讀性、可維護性和自動化效率（如生成 ChangeLog）。以下是常見的?Conventional Commits?規范，結合社區最佳實踐總結而成：
1. 提交格式
每次提交的?commit message?應包含三部分：Header、Body?和?Footer，格式如下：
復制
<type>(<scope>): <subject> <空行> <body> <空行> <footer>
-
Header（必填）：描述提交類型和簡短說明。
-
Body（可選）：詳細說明修改內容（如動機、實現細節）。
-
Footer（可選）：關聯 Issue、描述破壞性變更（BREAKING CHANGE）等。
2. 提交類型（Type）
| 類型 | 說明 |
|---|---|
feat | 新增功能（feature） |
fix | 修復 Bug |
docs | 文檔更新（如 README、注釋） |
style | 代碼樣式調整（如空格、格式化，不改變邏輯） |
refactor | 代碼重構（既不修復 Bug 也不新增功能） |
perf | 性能優化 |
test | 添加或修改測試用例 |
chore | 構建過程或輔助工具的變動（如依賴更新、CI 配置） |
revert | 回滾之前的提交 |
build | 構建相關的修改（如打包工具、依賴庫版本升級） |
ci | CI/CD 配置或腳本的修改 |
3. 規范細則
Header
-
<type>：必填，從上述類型中選擇。 -
<scope>：可選，描述影響范圍（如模塊名、功能名），例如?feat(user)。 -
<subject>：簡明描述修改內容：-
使用祈使句（如 "Add" 而非 "Added" 或 "Adds"）。
-
首字母小寫，結尾不加標點。
-
長度建議不超過?50 字符。
-
Body
-
描述為什么修改、如何修改，以及與之前行為的對比。
-
每行不超過?72 字符，避免自動換行問題。
Footer
-
關聯 Issue：如?
Closes #123?或?Fixes #456。 -
破壞性變更：以?
BREAKING CHANGE:?開頭，描述不兼容的改動。
4. 提交示例
plaintext
復制
feat(auth): add OAuth2 login support- Integrate Google OAuth2 API - Add login button componentCloses #123 BREAKING CHANGE: Remove deprecated login API endpoints.
plaintext
復制
fix(api): handle null response in user endpointWhen the user data is missing, return 404 instead of 500.Fixes #456
5. 工具支持
-
commitlint：校驗提交信息是否符合規范。 -
husky：通過 Git 鉤子自動觸發校驗。 -
standard-version：基于提交記錄自動生成版本號和 ChangeLog。
6. 分支命名建議
-
功能分支：
feature/描述性名稱（如?feature/user-login） -
Bug 分支：
fix/問題描述（如?fix/login-error） -
熱修復分支：
hotfix/問題描述
通過規范化的提交信息，可以：
-
提升代碼審查效率。
-
自動化生成版本日志（ChangeLog）。
-
方便追蹤代碼變更歷史。
-
支持語義化版本號（Semantic Versioning）。
以下是一些符合中文 Git 提交規范的示例，涵蓋不同場景：
示例 1：新增功能（feat）
plaintext
復制
feat(訂單): 新增支持支付寶支付方式- 添加支付寶 SDK 集成 - 創建支付結果回調處理邏輯 - 更新訂單狀態流轉文檔Closes #45
示例 2：修復 Bug（fix）
plaintext
復制
fix(登錄): 修復手機號驗證碼重復發送問題當用戶頻繁點擊發送驗證碼按鈕時，后端未正確校驗時間間隔， 導致同一用戶 1 秒內可發送多次請求。現已添加 60 秒冷卻時間限制。Fixes #78
示例 3：文檔更新（docs）
plaintext
復制
docs(API): 更新用戶模塊接口文檔- 補充 getUserInfo 接口的權限說明 - 修正 createUser 的請求體示例格式
示例 4：代碼重構（refactor）
plaintext
復制
refactor(購物車): 解耦商品價格計算邏輯將價格計算從 ShoppingCartService 移至獨立的 PriceCalculator 類， 提高代碼可測試性和可維護性。
示例 5：破壞性變更（BREAKING CHANGE）
plaintext
復制
feat(配置): 重構環境變量加載方式- 廢棄舊版 .env 文件格式 - 改用 YAML 格式配置文件BREAKING CHANGE: 必須將原有 .env 文件遷移至 config.yaml Closes #112
示例 6：簡單提交（無 Body/Footer）
plaintext
復制
style: 調整首頁按鈕間距
示例 7：性能優化（perf）
plaintext
復制
perf(圖片加載): 啟用 WebP 格式壓縮- 通過 CDN 自動轉換圖片為 WebP 格式 - 平均圖片體積減少 65%
示例 8：回滾提交（revert）
plaintext
復制
revert: 撤銷 "feat: 實驗性分頁功能"該功能導致列表渲染性能下降超過 200ms， 需重新設計實現方案。This reverts commit 9a7b2d1c.
示例 9：測試相關（test）
plaintext
復制
test(用戶服務): 添加登錄失敗用例- 覆蓋密碼錯誤、賬號鎖定等場景 - 使用 Jest 模擬 Redis 服務
示例 10：構建工具（build）
plaintext
復制
build: 升級 Webpack 至 5.75 版本- 修復 tree-shaking 對 lodash 的兼容性問題 - 優化構建產物哈希生成策略
關鍵要點
-
動詞使用：描述時用 "新增/修復/優化/調整" 等祈使動詞
? 錯誤："修復了XXX問題" → ? 正確："修復XXX問題" -
長度控制：
-
Header 簡明扼要（50 字內）
-
Body 每行不超過 72 字符
-
-
關聯問題：明確標注關閉的 Issue（如?
Closes #123） -
破壞性變更：必須用?
BREAKING CHANGE:?顯式聲明
實際使用中可根據團隊需求調整規范細節，建議配合?Commitizen?工具實現交互式提交引導。
)
)
