1、背景

在多人協作項目中，如果代碼風格統一、代碼提交信息的說明準確，那么在后期協作以及Bug處理時會更加方便。

因此，在本文章中，我會介紹怎么使用下面這個工具，在git push 代碼之前檢測commit messages：

commitlint
husky

2、先來介紹博主采用的commit規范

Commit message格式

<type>: <subject>

注意冒號后面有空格。
type

用于說明 commit 的類別，只允許使用下面7個標識。

Deat：新功能（feature）
Fix：修補bug
Docs：文檔（documentation）
Style： 格式（不影響代碼運行的變動）
Refactor：重構（即不是新增功能，也不是修改bug的代碼變動）
Test：增加測試
Chore：構建過程或輔助工具的變動

如果type為feat和fix，則該 commit 將肯定出現在 Change log 之中。
subject

subject是 commit 目的的簡短描述，不超過50個字符，且結尾不加句號（.）。

3. 使用工具校驗commit是否符合規范

3.1 全局安裝

3.2 生成配置配件

這個文件在根目錄下生成就可以了。

3.2 在commitlint.config.js制定提交message規范

上面我們就完成了commitlint的安裝與提交規范的制定。檢驗commit message的最佳方式是結合git hook，所以需要配合Husky

3.4 husky介紹

husky繼承了Git下所有的鉤子，在觸發鉤子的時候，husky可以阻止不合法的commit,push等等。注意使用husky之前，必須先將代碼放到git 倉庫中，否則本地沒有.git文件，就沒有地方去繼承鉤子了。

安裝成功后需要在項目下的package.json中配置

最后我們可以正常的git操作

git commit的時候會觸發commlint。下面演示下不符合規范提交示例：

上面message不符合提交規范，所以會提示錯誤。

我們修改下type

commit成功。

3.5 husky的鉤子

可以在package.json下面添加如下的鉤子。

4、最后總結過程中遇到一些問題

1. git commit后可能報錯相關‘regenerator-runtime’模塊找不到；解決方式：npm install regenerator-runtime –save。
2. git commit -m “messge”,用雙引號

[轉載自]https://blog.csdn.net/y491887095/article/details/80594043