需求
配置使得在git commit -m 'xxxx’時，先執行1. eslint檢測 2.commit規範檢測，兩個條件通過後才commit成功，纔可以push代碼。是前端工程化的一部分，使得代碼及commit更加規範
commitlint
commitlint: 可以幫助我們 lint commit messages, 如果提交的不符合指向的規範, 拒絕提交
需要一份校驗的配置, 這裏推薦 @commitlint/config-conventional (符合 Angular團隊規範).
安裝:
npm install @commitlint/config-conventional @commitlint/cli --save
同時需要在項目目錄下創建配置文件 .commitlintrc.js, 寫入:
module.exports={extends:['@commitlint/config-conventional'],rules:{}};
rules可以自己設置團隊規範，我沒設，用的angular團隊規範
husky
commitlint配置完成後還要配置husky。husky是git的hook（鉤子）工具
【git鉤子】
就像vue的生命週期鉤子函數，Git 能在特定的重要動作發生時觸發自定義腳本。有兩組這樣的鉤子：客戶端的和服務器端的。 客戶端鉤子由諸如提交和合併這樣的操作所調用，而服務器端鉤子作用於諸如接收被推送的提交這樣的聯網操作。
【提交鉤子有】：（後面會有詳細解釋）
pre-commit
prepare-commit-msg
commit-msg
post-commit
前端則可以用插件husky來使鉤子生效。
安裝
npm install husky --save
配置
在package.json中配置
"husky": {
"hooks": {
"commit-msg": "commitlint -e $GIT_PARAMS"
}
}
這段配置的意思是：在’commit-msg’這個鉤子內獲取commit裏的內容進行commitlint檢測，如果果該鉤子腳本以非零值退出，Git 將放棄提交
此時我如果提交不符合規範的commit，結果如下
$ git commit -m "測試 commitlint"
husky > commit-msg (node v10.13.0)
⧗ input:
測試 commitlint
✖ message may not be empty [subject-empty]
✖ type may not be empty [type-empty]
✖ found 2 problems, 0 warningshusky > commit-msg hook failed (add --no-verify to bypass)
可以看到如果不按照規範書寫commit的日誌會提示報錯
下面輸入正確的commit 日誌信息：注意冒號後面要留空格，下面有介紹具體的編輯規範信息
$ git commit -m "feat(): 添加commitlint"
husky > commit-msg (node v10.13.0)
⧗ input: feat(): 添加commitlint
✔ found 0 problems, 0 warnings[master 7a5bc00] feat(): 添加commitlint
4097 files changed, 219349 insertions(+)
create mode 100644 commitlint.config.js
create mode 120000 node_modules/.bin/JSONStream
create mode 120000 node_modules/.bin/commitlint
create mode 120000 node_modules/.bin/conventional-commits-parser
下面就可以push了
新需求
按理來說這樣已經成功了，但希望commitlint檢測失敗後有提示後再退出。比如如下效果
那就需要對husky的配置進行修改，修改涉及到shell腳本知識
"husky": {
"hooks": {
"commit-msg": "commitlint -e $GIT_PARAMS || (node scripts/pre-commit.js&&exit 8)"
}
}
對於shell1||shell2，只有在shell1執行失敗時，shell2纔會執行，否則shell2是不執行的
所以以上配置的意思是commitlint -e $GIT_PARAMS失敗時，執行
(node scripts/pre-commit.js&&exit 8)
即執行package.json所在文件夾下的scripts/pre-commit.js文件後退出
詳細shell見shell中&&和||的使用方法
項目目錄如下
pre-commit.js文件內容如下，要npm install chalk --save，引入chalk模塊，作用是爲了讓console出來的有顏色。。。
const chalk = require('chalk');
console.log(
chalk.red(`commit格式錯誤，正確示例：git commit -m 'fix: 修復bug'`),
chalk.green(`
type （只允許下列7個標識）：
feat：新功能（feature）
fix：修補bug
docs：文檔（documentation）
style： 格式（不影響代碼運行的變動）
refactor：重構（即不是新增功能，也不是修改bug的代碼變動）
test：增加測試
chore：構建過程或輔助工具的變動
`)
)
這樣就配置完成了，可以達到效果了
加上eslint
完成後，又希望提交的代碼都符合eslint規範，如果不符合規範不能提交，所以在pre-commit鉤子里加上eslint檢查，配置如下,執行npm run lint
"husky": {
"hooks": {
"pre-commit": "npm run lint",
"commit-msg": "commitlint -e $GIT_PARAMS || (node scripts/pre-commit.js && exit 8)"
}
}
這樣就配置完了
eslint檢測不通過提交不了，要想解決eslint錯誤可以看解決eslint報錯
git鉤子詳解
剛纔用到了pre-commit, commit-msg，解釋如下，有點像vue的生命週期鉤子函數，在提交前依次執行，我這裏把eslint檢查放在pre-commit裏，commitlint檢查放commit-msg裏
具體：自定義 Git - Git 鉤子
pre-commit 鉤子在鍵入提交信息前運行。 它用於檢查即將提交的快照，例如，檢查是否有所遺漏，確保測試運行，以及覈查代碼。 如果該鉤子以非零值退出，Git 將放棄此次提交，不過你可以用 git commit --no-verify 來繞過這個環節。 你可以利用該鉤子，來檢查代碼風格是否一致（運行類似 lint 的程序）、尾隨空白字符是否存在（自帶的鉤子就是這麼做的），或新方法的文檔是否適當。
prepare-commit-msg 鉤子在啓動提交信息編輯器之前，默認信息被創建之後運行。 它允許你編輯提交者所看到的默認信息。 該鉤子接收一些選項：存有當前提交信息的文件的路徑、提交類型和修補提交的提交的 SHA-1 校驗。 它對一般的提交來說並沒有什麼用；然而對那些會自動產生默認信息的提交，如提交信息模板、合併提交、壓縮提交和修訂提交等非常實用。 你可以結合提交模板來使用它，動態地插入信息。
commit-msg 鉤子接收一個參數，此參數即上文提到的，存有當前提交信息的臨時文件的路徑。 如果該鉤子腳本以非零值退出，Git 將放棄提交，因此，可以用來在提交通過前驗證項目狀態或提交信息。 在本章的最後一節，我們將展示如何使用該鉤子來覈對提交信息是否遵循指定的模板。
post-commit 鉤子在整個提交過程完成後運行。 它不接收任何參數，但你可以很容易地通過運行 git log -1 HEAD 來獲得最後一次的提交信息。 該鉤子一般用於通知之類的事情。
commit message規範
那麼什麼樣的是符合規範的commit message？
一般就是
type(scope): subject
例子：
fix: 修復bug
type:種類，必寫
scope：影響範圍 可以不寫
subject：簡短說明，50字符內
其實還有body,foot什麼的，我覺得寫個subject簡短說明就夠了，難不成還在commit裏寫作文
注意:冒號後面一定要加空格，否則不能通過commitlint驗證
type有以下幾種：
- feat：新功能（feature）
- fix：修補bug
- docs：文檔（documentation）
- style： 格式（不影響代碼運行的變動）
- refactor：重構（即不是新增功能，也不是修改bug的代碼變動）
- test：增加測試
- chore：構建過程或輔助工具的變動