提交規範
本文件描述了 Rin 專案的提交訊息規範。遵循這些規範可以讓我們自動產生變更日誌與發布說明。
格式
每則提交訊息應遵循以下格式:
類型
作用範圍
作用範圍是選用的,應指出受影響的程式碼區域:
api- 後端 API 變更client- 前端/用戶端變更db- 資料庫變更auth- 認證相關ui- UI 元件deps- 相依套件config- 設定檔docs- 文件release- 發布相關
主旨
- 使用祈使語氣(「新增」而非「新增了」或「新增」)
- 首字母不大寫
- 結尾不加句號
- 最多 50 個字元
好的範例:
feat(auth): 新增密碼重設功能fix(api): 處理資料庫空回應docs(readme): 更新安裝說明
不好的範例:
feat: Added new feature(過去式,首字母大寫)fix: fixed the bug.(過去式,結尾有句號)update stuff(無類型,描述模糊)
內文
- 使用祈使語氣
- 每行 72 個字元處斷行
- 解釋做了什麼與為什麼,而非怎麼做
- 與主旨之間以空行分隔
範例:
頁尾
- 引用 Issue 與 PR:
Closes #123、Fixes #456 - 破壞性變更:
BREAKING CHANGE: 描述
範例:
範例
功能
Bug 修正
文件
破壞性變更
提交訊息檢查
我們建議使用 commitlint 來強制執行這些規範:
為什麼?
- 自動產生變更日誌:可以自動產生發布說明
- 清楚的歷史記錄:容易理解發生了哪些變更以及原因
- 語意化版本控制:協助判定版本升級(feat=minor,fix=patch,breaking=major)
- 更好的協作:一致的格式讓程式碼審查更容易
工具
-
Commitizen:互動式提交訊息建構器
-
VS Code 擴充套件:「Conventional Commits」用於自動完成
有問題?
如果您不確定提交類型或格式,請在您的 PR 中詢問,或參考倉庫中既有的提交。