在協作軟體開發團隊中，提交訊息結構的不一致會使追蹤變更變得困難。諸如 fix bug、update code 或 minor changes 之類的模糊提交訊息會使程式碼審核和延遲發布文件變得複雜。
為了解決此問題並維護乾淨、機器可讀的提交歷史記錄，世界各地的開發人員採用常規提交規範。
在本文中，我們將解釋常規提交的結構、標準前綴分類，以及該規則如何實現自動發布操作。
1. 常規提交的結構
常規提交為提交日誌建立了標準化佈局。核心模板結構如下：
<type>(<scope>): <description>
[optional body]
[optional footer(s)]
- 類型：更改的意圖（必填）
- 範圍：受影響的模組或子系統（可選，例如
auth、payment） - 描述：變更的簡明摘要（必填）
- 正文：深入的解釋或理由（可選）
- 頁腳：重大變更或參考 ID（可選，例如
Refs #104）
實際例子：
feat(auth): increase minimum password length requirement to 8 characters
To align with modern security policies, all login registrations and credential updates
now validate that passwords are at least 8 characters long.
Closes #142
2. 標準類型及意義
選擇正確的類型前綴是保持歷史有意義的關鍵。 以下是標準類型：
| 類型 | 定義 |
|---|---|
| 壯舉 | 在程式碼庫中引入了一項新功能。 |
| 修復 | 修補應用程式中的錯誤。 |
| 文檔 | 文檔的修改（例如自述文件或內聯註釋）。 |
| 風格 | 非功能性變更（格式、分號、空格調整）。 |
| 重構 | 程式碼重組既不修復錯誤也不添加功能。 |
| 效能 | 效能最佳化修訂。 |
| 測試 | 新增缺少的測試或修復現有測試。 |
| 家務 | 日常任務（依賴項、建置配置、npm 套件）。 |
| ci | CI 管道調整（例如 GitHub Actions 工作流程文件）。 |
3. 實施常規提交的好處
① 可讀可搜尋的歷史記錄
標準化前綴使提交日誌易於掃描。您可以立即篩選提交以僅查看在給定時間範圍內新增的錯誤 (fix) 或功能 (feat)。
② 自動產生 CHANGELOG
由於提交是結構化的，因此 standard-version 或 release-it 等工具可以解析您的 git 歷史記錄，並在發布週期中自動輸出格式化的 CHANGELOG.md 檔案。
③ 語意版本控制（SemVer）自動化
進階發布系統（如 semantic-release）讀取常規提交以自動計算版本增量：
fix觸發 Patch 版本提升（例如1.0.0->1.0.1）。feat觸發 次要 版本提升（例如1.0.0->1.1.0）。BREAKING CHANGE頁腳會觸發 主要 版本變更（例如1.0.0->2.0.0）。
結論
適應傳統提交可能需要簡短的調整，但在清晰度、文件品質和管道自動化方面的回報是巨大的。開始將這些前綴整合到您的開發工作流程中，以建立更清晰的專案歷史記錄。