實用工具
輸入
結果
結果會顯示在這裡。Conventional Commits（約定式提交）——feat(api): add streaming、fix: handle empty responses——是 semantic-release、release-please 和各種變更紀錄產生器用來決定下一個版本號、撰寫版本說明的格式，而 commitlint 是大多數專案用來強制執行它的工具。貼上一則或多則提交訊息，這個檢查器會套用 @commitlint/config-conventional 的規則：允許的類型、類型小寫、描述不以大寫開頭也不以句號結尾、標題最多 100 個字元、內文和頁尾前要空一行。每個問題都以 commitlint 自己的措辭和規則名稱回報，所以在這裡改好的，就是提交 hook 會抓出來的。
它是怎麼運作的
- 規則依 commitlint 原始碼重新實作，並不會執行 commitlint 本身，所以檢查在頁面裡完成；規則集、嚴重程度和提示與 config-conventional 一致。
- 多則訊息之間以只有 --- 的一行分隔。合併提交、revert、fixup!/squash! 提交，以及只有版本號的發布提交會略過，與 commitlint 的預設行為相同。
- 破壞性變更——類型後面的 !，或 BREAKING CHANGE: 頁尾——會特別指出，因為發布工具會據此提升主版本號。
- 有一項是 commitlint 沒有的：小寫的 breaking change: 頁尾會收到警告，因為規範要求這個標記全部大寫，解析器會忽略其他寫法。
你的資料去了哪裡
哪也沒去。本工具完全在你的瀏覽器裡執行：你貼上的文字由頁面處理，不會傳輸到任何伺服器，也不會寫進任何紀錄。
本工具免費且免登入，執行結果只存在於你目前的頁面裡，不會被儲存到任何地方。
它要花多少
本工具完全免費，不需要登入，也不消耗點數。
常見問題
- 允許哪些類型？
- config-conventional 接受的十一種：build、chore、ci、docs、feat、fix、perf、refactor、revert、style 和 test。其他寫法——首字母大寫的 Fix、feature、update——都不符合 type-enum 規則。專案可以在自己的 commitlint 設定裡擴充這份清單；這個檢查器使用的是預設設定。
- 為什麼 "feat: Add login page" 會報錯？
- config-conventional 禁止描述使用 sentence case、start case、pascal case 和 upper case，所以描述不能以大寫字母開頭，除非那個字本來就這樣寫。應寫成 feat: add login page。專有名詞可以加上引號或反引號保留，大小寫檢查會略過它們。
- 可以用中文寫提交訊息嗎？
- 可以。大小寫只存在於拉丁、希臘、西里爾等文字中，所以像 更新安裝說明 這樣的描述能通過大小寫規則。但類型仍必須是英文關鍵字：docs(readme): 更新安裝說明 合格，文件: 更新安裝說明 則不合格。
- 標題上限為什麼是 100 而不是 72？
- 100 是 config-conventional 的預設值。很多團隊偏好 72，這樣在 git log --oneline 和 GitHub 的提交清單裡標題不會被截斷；把標題最大長度設為 72，就能依這個標準檢查。
背後的開源專案
本工具是獨立實作，並未打包第三方函式庫。conventional-changelog/commitlint（MIT）在程式碼層面做的是同一件事——如果你需要在自己的程式裡實作它，從那裡開始，而不是呼叫一個網頁。
conventional-changelog/commitlint也常被稱作
- commit message 檢查
- conventional commits 規範
- commitlint 線上
- git 提交訊息規範
- 約定式提交
- 提交訊息格式