前端提交信息規范——commitlint

一 安裝

需要先保證安裝過依賴 husky

npm install --save-dev husky

安裝@commitlint/config-conventional @commitlint/cli

npm install --save-dev @commitlint/config-conventional @commitlint/cli

二 配置

生成配置文件commitlint.config.js，當然也可以是 .commitlintrc.js

echo "module.exports = {extends: ['@commitlint/config-conventional']};" > commitlint.config.js

在husky的配置加入CommitlIint配置，v1.0.1版本以后為HUSKY_GIT_PARAMS，v0.14.3為GIT_PARAMS

"husky": {
    "hooks": {
      "commit-msg": "commitlint -e $HUSKY_GIT_PARAMS"
    }
  },

三 提交規范

3.1 提交格式（注意冒號后面有空格）

git commit -m <type>[optional scope]: <description>

3.1.1 常用的type類別

type ：用於表明我們這次提交的改動類型，是新增了功能？還是修改了測試代碼？又或者是更新了文檔？總結以下 11 種類型：

• build：主要目的是修改項目構建系統(例如 glup，webpack，rollup 的配置等)的提交
• ci：主要目的是修改項目繼續集成流程(例如 Travis，Jenkins，GitLab CI，Circle等)的提交
• docs：文檔更新
• feat：新增功能
• fix：bug 修復
• perf：性能優化
• refactor：重構代碼(既沒有新增功能，也沒有修復 bug)
• style：不影響程序邏輯的代碼修改(修改空白字符，補全缺失的分號等)
• test：新增測試用例或是更新現有測試
• revert：回滾某個更早之前的提交
• chore：不屬於以上類型的其他類型(日常事務)

optional scope：一個可選的修改范圍。用於標識此次提交主要涉及到代碼中哪個模塊。

description：一句話描述此次提交的主要內容，做到言簡意賅。

例子：

git commit -m 'feat: 增加 xxx 功能'
git commit -m 'bug: 修復 xxx 功能'

3.1.2 subject

subject是 commit 目的的簡短描述，可以做一些配置，如最大長度限制。

3.2 commitlint.config.js文件配置

rule配置說明:：rule由name和配置數組組成，如：'name:[0, 'always', 72]'，數組中第一位為level，可選0,1,2，0為disable，1為warning，2為error，第二位為應用與否，可選always|never，第三位該rule的值。具體配置例子如下：

module.exports = {
  extends: [
    "@commitlint/config-conventional"
  ],
  rules: {
    'type-enum': [2, 'always', [
      'upd', 'feat', 'fix', 'refactor', 'docs', 'chore', 'style', 'revert'
     ]],
    'type-case': [0],
    'type-empty': [0],
    'scope-empty': [0],
    'scope-case': [0],
    'subject-full-stop': [0, 'never'],
    'subject-case': [0, 'never'],
    'header-max-length': [0, 'always', 72]
  }
};

這里列出了大部分常用的配置，其它的可以參考Commitlint網站