本文的目的是為了給想要快速搭建一套業內流行的angular團隊程式碼提交規範（不是angular團隊編寫程式碼的規範）的小夥伴們提供一個簡單清晰直白的教程。文章的內容不會深究每個環節的細節，但是會用通俗的話語讓需要的小夥伴們瞭解每個環節的含義和作用，從而能做到從0到1的搭建起程式碼提交的工作流。
第一步、格式化commit message
commit message的重要性我就不在這強調了，我們常規提交程式碼都是通過git commit -m "xxx"附上一句話來描述此次程式碼的改動，這樣的方式對於一些影響範圍大或者broken式的改動來說太過於簡單隨意。每個人都有自己習慣的提交程式碼方式，所以我們需要藉助一個工具來生成符合規範的commit message並約束提交的人。
commitizen是一個格式化commit message的工具，可以約束提交者按照制定的規範一步一步的填寫commit message。
區域性安裝
npm i -D commitizen
配置：
package.json中寫入：
"script": {
...,
"commit": "git-cz",
}
複製程式碼這樣我們就可以藉助commitizen提供的git-cz，用npm run commit命令來替代git commit命令。
第二步、採用angular團隊提交的規範
我們已經把可以生成指定commit message的工具commitizen安裝好了，接下來要做的就是為commitizen制定一套填寫規範。
cz-conventional-changelog is a commitizen adapter for the angular preset of conventional-changelog （一套適用於commitizen的angular團隊規範）。目前採用比較廣泛，那我們就直接給commitizen引用這套規範了。
區域性安裝
npm i -D cz-conventional-changelog
配置：
package.json中寫入：
"config": {
"commitizen": {
"path": "node_modules/cz-conventional-changelog"
}
}
複製程式碼安裝配置好以後，執行npm run commit就會出現如下引導式填寫：
第三步、校驗commit message
雖然之前兩步已經約束了一套程式碼提交規範，但是還是有人不按照規範提交程式碼怎麼辦呢？這個時候就需要commitlint來幫助我們校驗commit message，拒絕不符合規範的commit message。
與eslint類似，commitlint也需要一份校驗的配置。彆著急，這裡有一份與cz-conventional-changelog規範（angular團隊規範）配套的校驗配置@commitlint/config-conventional來幫助我們檢驗commit message的合規性。
區域性安裝
npm i -D @commitlint/config-conventional @commitlint/cli
配置
安裝完成以後，同時需要在專案根目錄下建立配置檔案commit.config.js或者.commitlintrc.js並寫入：
module.exports = {
extends: [
'@commitlint/config-conventional'
]
}
複製程式碼或者在package.json中寫入：
"commitlint": {
"extends": [
"@commitlint/config-conventional"
]
},
複製程式碼commitlint就可以運用config-conventional這套校驗配置。
第三步、配置校驗時機
到了第三步我們的程式碼提交約束規範已經基本成型了，最後一步要做的就是配置觸發commit message校驗的時機。
校驗commit message的最佳姿勢是git hook和husky的結合。
husky（哈士奇）是個什麼東西呢？簡單來說就是個能讓你在每個git鉤子中配置相應行為的一個工具。
區域性安裝
npm install husky --save-dev
配置
安裝完成以後，同時需要在專案根目錄下建立配置檔案.huskyrc或者.huskyrc.js檔案並寫入：
{
"husky": {
"hooks": {
...,
"commit-msg": "commitlint -e $GIT_PARAMS"
}
}
}
複製程式碼或者在package.json中寫入：
"husky": {
"hooks": {
...,
"commit-msg": "commitlint -e $GIT_PARAMS"
}
}
複製程式碼在git commit-msg這個鉤子中會觸發commitlint的操作。
第四步、自動化程式碼檢查
其實前三步已經打造好了基於angular團隊程式碼提交規範的工作流了，但是如果我們在提交程式碼的時候不僅僅需要校驗commit message的規範性還要校驗程式碼的正確性呢？
lint-staged可以讓你每次只對你此次提交所在暫存區的檔案（git add後的檔案）進行一系列的檢查、修復、格式化操等作。
區域性安裝
npm install -D lint-staged
配置
安裝完成以後，同時需要在專案根目錄下建立配置檔案.lintstagedrc並寫入：
{
"*.{js,vue}": ["eslint --fix", "git add"]
}
複製程式碼或者在package.json中寫入：
"lint-staged": {
"*.{js,vue}": ["eslint --fix", "git add"]
}
複製程式碼在第三步建立的husky配置檔案進行補充：
"husky": {
"hooks": {
"pre-commit": "lint-staged",
"commit-msg": "commitlint -e $GIT_PARAMS"
}
}
複製程式碼在pre-commit這個鉤子中，lint-staged會執行.lintstagedrc配置的操作（列出來的配置的意思是對本次提交的js或者vue檔案進行eslint檢查並修復，並且把修復過後的檔案再重新提交到暫存區）。
第五步、生成CHANGELOG
conventional-changelog-cli可以自動根據commit message生成CHANGELOG。
區域性安裝
npm install conventional-changelog-cli --save-dev
配置
"scripts": {
...,
"version": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0 && git add CHANGELOG.md"
}
複製程式碼執行npm run version就能生成CHANGELOG.md檔案。因為CHANGELOG適用於有版本迭代的工具開發（不適用於業務程式碼），來記錄每個版本的改動，所以需要先使用npm version [version]更改版本號，再生成CHANGELOG，這樣生成的CHANGELOG只對應著你這次修改的版本。
最後
一個完整的基於angular團隊程式碼提交規範的工作流已經打造完成，如果有不適應angular這套規範的話也可以自定義一套規範，這裡就不再贅述了。也有可能有的小夥伴覺得這麼寫commit很麻煩，但是一個好的提交規範習慣有助於整個團隊在專案中高效率的開發，所以趕緊在自己專案中用起來吧！