前言
在一個團隊中,每個人的git的commit信息都不一樣,五花八門,沒有一個機制很難保證規范化,如何才能規范化呢?可能你想到的是git的hook機制,去寫shell腳本去實現。這當然可以,其實JavaScript有一個很好的工具可以實現這個模板,它就是commitlint。
接下來將會講解如何一步步的使用commitlint。
安裝husky
husky是一個git hook的管理工具,實現了大部分的git hook,有興趣的可以自行google。一般情況下,commitlint會用在git的hook回調中,如果不想自己寫githooks,那么最簡單的就是和 husky一起使用。
npm install --save-dev husky
在package.json中配置husky. hooks
{ "husky": { "hooks": { "pre-commit": "echo 我要提交代碼啦", "commit-msg": "commitlint -E HUSKY_GIT_PARAMS", "pre-push": "echo 我要推送代碼啦" } } }
通過HUSKY_GIT_PARAMS傳遞參數,-E|--env用於指向相關的編輯文件。
npm install --save-dev @commitlint/config-conventional @commitlint/cli // 或者 npm install --save-dev @commitlint/{cli,config-conventional}
根目錄增加其配置文件commitlint.config.js
module.exports = { extends: ['@commitlint/config-conventional'], };
一般情況下,默認的就夠用了。
當然,如果需要自定義限制這些規則,不啟用默認的規則,可以把配置寫的更詳細
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] } };
rule配置說明::rule由name和配置數組組成,如:'name:[0, 'always', 72]',數組中第一位為level,可選0,1,2,0為disable,1為warning,2為error,第二位為應用與否,可選always|never,第三位該rule的值。
具體配置項參考其官方文檔
提交注意
commitlint 的默認格式為
# 注意:冒號前面是需要一個空格的, 帶 ? 表示非必填信息 type(scope?): subject body? footer?
正確的例子
git commit -m 'feat: 增加 xxx 功能' git commit -m 'bug: 修復 xxx 功能'
scope 指 commit 的范圍(哪些模塊進行了修改)
subject 指 commit 的簡短描述
body 指 commit 主體內容(長描述)
footer 指 commit footer 信息
type 指當前 commit 類型,一般有下面幾種可選類型:
類型 | 描述 |
---|---|
build | 主要目的是修改項目構建系統(例如 glup,webpack,rollup 的配置等)的提交 |
ci | 主要目的是修改項目繼續集成流程(例如 Travis,Jenkins,GitLab CI,Circle等)的提交 |
docs | 文檔更新 |
feat | 新增功能 |
merge | 分支合並 Merge branch ? of ? |
fix | bug 修復 |
perf | 性能, 體驗優化 |
refactor | 重構代碼(既沒有新增功能,也沒有修復 bug) |
style | 不影響程序邏輯的代碼修改(修改空白字符,格式縮進,補全缺失的分號等,沒有改變代碼邏輯) |
test | 新增測試用例或是更新現有測試 |
revert | 回滾某個更早之前的提交 |
chore | 不屬於以上類型的其他類型 |