看完 《前端規(guī)范之Git工作流規(guī)范（Husky + Commitlint + Lint-staged）https://www.cnblogs.com/Yellow-ice/p/15349873.html》养距，再次修改本文
團(tuán)隊(duì)人一多诉探，提交一多，還是要對(duì)備注加以區(qū)分棍厌，好快速找到變更點(diǎn)肾胯。這時(shí)候就需要對(duì)每次提交，需要輸入message耘纱，對(duì)提交的備注進(jìn)行規(guī)范化處理
代碼規(guī)范落地難：歸根結(jié)底在于需要工具去強(qiáng)行保證代碼必須經(jīng)過(guò)代碼開(kāi)發(fā)規(guī)范的掃描敬肚；
低質(zhì)量代碼帶入線上應(yīng)用：最好的方式本地進(jìn)行commit的時(shí)候，最起碼需要保證當(dāng)前代碼能夠滿足團(tuán)隊(duì)制定的開(kāi)發(fā)規(guī)范束析，如果不通過(guò)艳馒，commit都無(wú)法成功，這樣能夠從最源頭保證代碼質(zhì)量問(wèn)題畸陡；
代碼格式難統(tǒng)一：需要一種工具強(qiáng)制保證團(tuán)隊(duì)內(nèi)代碼的格式是一致鹰溜；
代碼質(zhì)量文化難落地：通過(guò)引入代碼質(zhì)量工具，在開(kāi)發(fā)過(guò)程中能夠時(shí)刻對(duì)自身代碼質(zhì)量進(jìn)行約束丁恭，逐漸培養(yǎng)自身對(duì)代碼質(zhì)量有“潔癖”的開(kāi)發(fā)觀念曹动，同時(shí)也會(huì)成為團(tuán)隊(duì)乃至自身對(duì)質(zhì)量文化落地的一個(gè)抓手。
要想防患于未然牲览，防止將存在潛在問(wèn)題的代碼帶到線上環(huán)境墓陈，最好的辦法是在本地提交代碼時(shí)就能夠掃描出潛在的錯(cuò)誤，并強(qiáng)制將其修改后才能提交第献，這樣就不會(huì)將問(wèn)題代碼攜帶到線上贡必，就能保證線上代碼至少不會(huì)存在低級(jí)的程序錯(cuò)誤。
有些同學(xué)可能會(huì)把ESLint庸毫、Stylelint或Commitizen提示的錯(cuò)誤忽視不見(jiàn)仔拟，直接將代碼提交到代碼倉(cāng)庫(kù)中。這樣做的話飒赃，那么其他同學(xué)在pull代碼并diff代碼時(shí)可能會(huì)出現(xiàn)大段代碼標(biāo)紅利花，同時(shí)在進(jìn)行CI時(shí)又可能因?yàn)榇a風(fēng)格或規(guī)范問(wèn)題被打回重改恋拷。
如何讓大家在提交代碼時(shí)需要確保本地的代碼或Commit Message已經(jīng)通過(guò)檢查才能夠push到代碼倉(cāng)庫(kù)艰亮，從而更好的保障代碼質(zhì)量呢？
可以用?Husky + Commintlint + Lint-staged打造規(guī)范的Git檢查工作流娃圆，確保我們的代碼只有符合規(guī)范才能提交到代碼倉(cāng)庫(kù)蔫慧。
什么是git hook
git hook挠乳，也就是常說(shuō)的Git鉤子。
Git能在特定的重要?jiǎng)幼靼l(fā)生時(shí)觸發(fā)自定義腳本。有兩組這樣的鉤子：客戶端的和服務(wù)器端的睡扬。
客戶端鉤子由諸如提交和合并這樣的操作所調(diào)用
服務(wù)器端鉤子作用于諸如接收被推送的提交這樣的聯(lián)網(wǎng)操作
客戶端鉤子我們可能用的比較多盟蚣，客戶端鉤子通常包括了提交工作流鉤子、電子郵件工作流鉤子和其它鉤子威蕉。這些鉤子通常存儲(chǔ)在項(xiàng)目的.git/hooks目錄下刁俭，我們需要關(guān)注的主要是提交工作流鉤子。提交工作流鉤子主要包括了以下四種：
pre-commit：該鉤子在鍵入提交信息前運(yùn)行韧涨。?它用于檢查即將提交的快照。如果該鉤子以非零值退出侮繁，Git 將放棄此次提交虑粥，你可以利用該鉤子，來(lái)檢查代碼風(fēng)格是否一致宪哩。
prepare-commit-msg：該鉤子在啟動(dòng)提交信息編輯器之前娩贷，默認(rèn)信息被創(chuàng)建之后運(yùn)行。 它允許你編輯提交者所看到的默認(rèn)信息锁孟。
commit-msg：該鉤子接收一個(gè)參數(shù)彬祖，此參數(shù)存有當(dāng)前提交信息的臨時(shí)文件的路徑。 如果該鉤子腳本以非零值退出品抽，Git 將放棄提交储笑，因此，可以用來(lái)在提交通過(guò)前驗(yàn)證項(xiàng)目狀態(tài)或提交信息圆恤。
post-commit：該鉤子一般用于通知之類的事情突倍。
在上面的鉤子中，我們需要關(guān)注pre-commit和commit-msg鉤子盆昙。
Commit message 格式
每次提交羽历，Commit message 都包括三個(gè)部分：header，body淡喜，footer
Git 提交備注規(guī)范
feat： 新增 feature
fix: 修復(fù) bug
docs: 僅僅修改了文檔秕磷，比如 README, CHANGELOG, CONTRIBUTE等等
style: 僅僅修改了空格、格式縮進(jìn)炼团、逗號(hào)等等澎嚣，不改變代碼邏輯
refactor: 代碼重構(gòu)，沒(méi)有加新功能或者修復(fù) bug
perf: 優(yōu)化相關(guān)们镜，比如提升性能币叹、體驗(yàn)
test: 測(cè)試用例，包括單元測(cè)試模狭、集成測(cè)試等
chore: 改變構(gòu)建流程颈抚、或者增加依賴庫(kù)、工具等
revert: 回滾到上一個(gè)版本
Git分支與版本發(fā)布規(guī)范
基本原則：master為保護(hù)分支，不直接在master上進(jìn)行代碼修改和提交贩汉。
開(kāi)發(fā)日常需求或者項(xiàng)目時(shí)驱富，從master分支上checkout一個(gè)feature分支進(jìn)行開(kāi)發(fā)或者bugfix分支進(jìn)行bug修復(fù)，功能測(cè)試完畢并且項(xiàng)目發(fā)布上線后匹舞，將feature分支合并到主干master褐鸥，并且打Tag發(fā)布，最后刪除開(kāi)發(fā)分支赐稽。分支命名規(guī)范：
分支版本命名規(guī)則：分支類型 _ 分支發(fā)布時(shí)間 _ 分支功能叫榕。比如：feature_20170401_fairy_flower
時(shí)間使用年月日進(jìn)行命名，不足2位補(bǔ)0
分支功能命名使用snake case命名法姊舵，即下劃線命名晰绎。
Tag包括3位版本，前綴使用v括丁。比如v1.2.31荞下。Tag命名規(guī)范：
新功能開(kāi)發(fā)使用第2位版本號(hào)，bug修復(fù)使用第3位版本號(hào)
核心基礎(chǔ)庫(kù)或者Node中間價(jià)可以在大版本發(fā)布請(qǐng)使用灰度版本號(hào)史飞，在版本后面加上后綴尖昏，用中劃線分隔。alpha或者belta后面加上次數(shù)构资，即第幾次alpha：v2.0.0-alpha.1抽诉、v2.0.0-belta.1
分支類型包括：feature、 bugfix蚯窥、refactor三種類型掸鹅，即新功能開(kāi)發(fā)、bug修復(fù)和代碼重構(gòu)
版本正式發(fā)布前需要生成changelog文檔拦赠，然后再發(fā)布上線
這些規(guī)范講出來(lái)巍沙，但是大家不一定完全遵守。所以荷鼠，需要對(duì)每次提交加鉤子句携，鏡像驗(yàn)證
Husky
husky是常見(jiàn)的git hook工具，使用husky可以掛載Git鉤子允乐，當(dāng)我們本地進(jìn)行g(shù)it commit或git push等操作前矮嫉，能夠執(zhí)行其它一些操作，比如進(jìn)行ESLint檢查牍疏，如果不通過(guò)蠢笋，就不允許commit或push。
具體參看：https://typicode.github.io/husky/#/
husky 運(yùn)行：
并在package.josn里添加如下命令
"prepare":?"husky?install"
運(yùn)行完會(huì)生成.husky文件夾鳞陨，在.husky文件夾下有一個(gè)pre-commit昨寞，這個(gè)文件是用來(lái)定義git commit之前應(yīng)該執(zhí)行什么命令，默認(rèn)內(nèi)容如下
#!/usr/bin/env?sh
.?"$(dirname?--?"$0")/_/husky.sh"
#npm?test
#自定義命令，手動(dòng)添加
npm?run?lint:eslint
npm?run?lint:stylelint
你可以進(jìn)行自定義命令援岩，來(lái)進(jìn)行提交前的校驗(yàn)
lint-staged
默認(rèn)情況下上面的命令會(huì)對(duì)所有的代碼進(jìn)行校驗(yàn)歼狼，這無(wú)疑是非常浪費(fèi)時(shí)間的。這時(shí)候我們需要借助 lint-staged
來(lái)對(duì)暫存的 git 文件運(yùn)行校驗(yàn)
具體查看：https://www.npmjs.com/package/lint-staged
在package.json 里添加如下代碼
{
??"lint-staged":?{
????"src/**/*.{less,scss,css}":?[
??????"stylelint?--fix?--syntax=less",
??????"git?add?."
????],
????"src/**/*.{js,ts,tsx,vue}":?[
??????"eslint?./src??--ext?.js,.tsx,.ts,.vue?--cache?--fix",
??????"git?add?."
????]
??},
??"scripts":?{
????"lint":?"eslint?--fix?src",
????"lint:style":?"stylelint?--fix?./**/*.{scss,css,vue}?--custom-syntax",
????"prepare":?"husky?install"
??},
??"devDependencies":?{
????"@blueking/eslint-config-bk":?"^2.1.0-beta.6",
????"@blueking/stylelint-config-bk":?"^2.0.0",
????"@commitlint/cli":?"^17.0.3",
????"@commitlint/config-conventional":?"^17.0.3",
????"bk-vision-cli":?"^4.0.4",
????"husky":?"^8.0.1",
????"lint-staged":?"^13.0.3",
??}
}
創(chuàng)建 commitlint.config.js
在根目錄下創(chuàng)建 .?commitlint.config.js
module.exports?=?{
??extends:?['@commitlint/config-conventional'],
??rules:?{
????'type-enum':?[
??????2,
??????'always',
??????[
????????'feature',
????????'feat',
????????'bug',
????????'fix',
????????'bugfix',
????????'refactor',
????????'perf',
????????'style',
????????'test',
????????'docs',
????????'info',
????????'format',
????????'merge',
????????'depend',
????????'chore',
????????'del',
??????],
????],
????'subject-valid':?[2,?'always'],
??},
??plugins:?[
????{
??????rules:?{
????????'subject-valid'({?subject?})?{
??????????console.log('it?is?a?subject',?subject);
??????????return?[
????????????/^[\s\S]+?(issue\s+#\d+)$/i.test(subject),
????????????'commit-msg?should?end?with?(issue?#{issueId})',
??????????];
????????},
??????},
????},
??],
};
工程結(jié)構(gòu)如下：
eslint
增加.eslintrc.js掃描規(guī)則：(.eslintrc.js)
module.exports?=?{
??root:?true,
??extends:?['@blueking/eslint-config-bk/tsvue3'],
??rules:?{
????'no-param-reassign':?0,
????'@typescript-eslint/naming-convention':?0
??}
};
style-lint
增加style-lint 規(guī)則(.stylelintrc.js)
module.exports?=?{
??defaultSeverity:?'error',
??extends:?['@blueking/stylelint-config-bk']
}
prettierr
增加.prettierrc.js文件享怀，用于在掃描通過(guò)后格式化代碼（該步驟可選羽峰，如果不引入prettier的話，相應(yīng)的在package和eslintrc中去除掉相應(yīng)配置即可）
module.exports?=?{
??printWidth:?80,
??semi:?true,
??singleQuote:?true,
??trailingComma:?'none',
??bracketSpacing:?true,
??jsxBracketSameLine:?false,
??arrowParens:?'avoid',
??requirePragma:?false,
??proseWrap:?'preserve'
};
加了鉤子后提交：git commit -m "XXX"添瓷，發(fā)現(xiàn)提交不了梅屉，報(bào)錯(cuò)
commit提交的時(shí)候報(bào)錯(cuò)
下面是常見(jiàn)的錯(cuò)誤
zsh: no matches found
因?yàn)闆](méi)有此配置：因?yàn)閦sh缺省情況下始終自己解釋這個(gè) *.h，而不會(huì)傳遞給 find 來(lái)解釋鳞贷。
vi ~/.zshrc
插入(i) ：etopt no_nomatch
保存退出（ese履植，qw)
執(zhí)行：source .zshrc
husky > pre-commit hook failed (add --no-verify to bypass)
提交代碼的時(shí)候,pre-commit(客戶端)鉤子，它會(huì)在Git鍵入提交信息前運(yùn)行做代碼風(fēng)格檢查悄晃。如果代碼不符合相應(yīng)規(guī)則，則報(bào)錯(cuò)凿滤，而它的檢測(cè)規(guī)則就是根據(jù).git/hooks/pre-commit文件里面的相關(guān)定義妈橄。
解決辦法：
進(jìn)入項(xiàng)目的.git文件夾(文件夾默認(rèn)隱藏,可先設(shè)置顯示或者命令ls查找),再進(jìn)入hooks文件夾,刪除pre-commit文件,重新git commit -m 'xxx' git push即可。
將git commit -m "XXX" 改為 git commit --no-verify -m "XXX"
參考文章：
eslint+husky+prettier+lint-staged提升前端應(yīng)用質(zhì)量 ：http://www.reibang.com/p/bea740c966e9
husky介紹及使用?https://www.cnblogs.com/jiaoshou/p/12222665.html
GitHook 工具 —— husky介紹及使用?https://www.cnblogs.com/jiaoshou/p/12222665.html
前端規(guī)范之Git工作流規(guī)范 Husky + lint-staged?https://blog.csdn.net/weixin_41897680/article/details/125233875
轉(zhuǎn)載本站文章《項(xiàng)目git commit時(shí)卡主不良代碼：husky讓Git檢查代碼規(guī)范化工作》,
請(qǐng)注明出處：https://www.zhoulujun.cn/html/tools/VCS/git/8582.html
