GitHooks上一节我们使用gitcz代替gitcommit实现了标准化的提交请求，但是还是有一些人会忘记使用问题。因此，在本节中，我们将研究这样一个问题以及我们应该如何解决它。先明确一下我们最终要达到的效果：我们希望当《提交描述信息》不符合约定的提交规范时，阻塞当前提交并抛出相应的错误信息。为了达到这个目的，我们首先需要了解一个叫做Githooks（githook||git回调方法）的概念，即：git在一个事件发生之前或之后执行一些其他的额外操作，我们期望阻止不符合要求的提交消息，然后我们需要使用钩子的Hook函数。以下是我整理的所有hook。你可以参考他们。加粗的是常用的hook：GitHook调用时机说明pre-applypatchgitam执行前applypatch-msggitam执行前post-applypatchgitam执行影响gitam的结果。预提交gitcommit可用于在执行前绕过commit-msggit。gitcommit--no-verify可用于在执行gitcommit之前绕过post-commit。gitcommit执行后不影响gitcommit因此pre-merge-commitgitmerge可以在执行前用gitmerge--no-verify绕过。执行prepare-commit-msggitcommit后，打开编辑器前，pre-rebase，执行gitrebase前，post-checkout，执行gitcheckout或gitswitch后，如果不带--no-checkout参数used，在gitclone之后也会执行。执行post-mergegitcommit后，执行gitpull时也会调用。pre-pushgitpush在执行pre-receivegit-receive-pack之前执行。updatepost-receivegit-receive-pack不影响git-receive-packpostafterexecution-updatepush-to-checkout当git-receive-pack响应gitpush更新仓库中的refspush-to-checkout当`git-receive-pack响应gitpush并更新存储库中的refs时，当push尝试更新当前签出的分支时，receive.denyCurrentBranch配置设置为updateInsteadpre-auto-gcgitgc--autoexecutionbeforepost-rewrite执行gitcommit--amend或gitrebasesendemail-validategitsend-email前执行fsmonitor-watchman配置core.fsmonitorp4-pre时设置为.git/hooks/fsmonitor-watchman或.git/hooks/fsmonitor-watchmanv2-submit可以用git-p4submit--no-verifybeforegit-p4submitexecute绕过p4-prepare-changelistgit-p4submit执行后，可以用git-p4submit--no-verifybeforeeditorstarts绕过p4-changelistgit-p4提交执行并编辑更改列表消息。可以使用git-p4submit--no-verify绕过p4-post-changelistgit-p4submit执行后将post-index-changeindex写入read-cache.cdo_write_locked_indexPS:详细的HOOKS介绍请点击在这里查看整体钩子。hooks有很多，但是其中其实用的比较多的只有两个：GitHook调用时机表示在执行pre-commitgitcommit之前不接受任何参数，在得到commitlogmessage和在进行提交之前通过调用的脚本gitcommit以非零状态退出会导致命令在创建提交之前中止。可以使用gitcommit--no-verify绕过commit-msggit可用于在提交前将消息规范化为某种项目标准格式。也可用于在检查消息文件后拒绝提交。可以使用gitcommit--no-verify来绕过这两个钩子，简单来说：commit-msg：可以用来规范标准格式，可以指定是否拒绝本次提交pre-commit：将在提交前调用,并且您可以根据需要指定是否要拒绝此提交。我们接下来要做的事情的关键就在这两个钩子上。使用husky+commitlint检查提交描述是否符合规范要求上一节我们了解了githooks的概念，接下来我们将使用githooks来验证我们的提交信息。为了完成这样的一个目标，我们需要用到两个工具：commitlint：用于检查commit信息husky：一个githooks工具注意：npm需要7.x以上版本！！！！！查看npm版本npm-vupgradenpmnpmi-gnpmcommitlint安装依赖：npminstall--save-dev@commitlint/config-conventional@12.1.4@commitlint/cli@12.1.4createcommitlint.config.jsfileecho"module.exports={extends:['@commitlint/config-conventional']}">commitlint.config.js打开commitlint.config.js，添加配置项（点击查看config-conventional默认配置）：module.exports={//继承规则extends:['@commitlint/config-conventional'],//定义规则类型规则:{//类型类型定义，表示git提交的类型必须在以下类型范围内'type-enum':[//当前验证的错误级别，2表示错误级别的错误2，//在什么情况下验证，always表示在任何情况下都验证'always',//通用内容，对应到cz-config定义的类型['feat',//newfeaturefeature'fix',//fixbug'docs',//documentcomment'style',//codeformat（不影响代码运行的更改）'refactor',//重构（既不添加新功能也不修复错误）'perf',//性能优化'test',//添加测试'chore',//更改为构建过程或辅助工具'revert',//回滚'build'//package]],//subjectcase不勾选'subject-case':[0]}}注意：一定要保存为UTF-8编码格式husky安装依赖：npminstallhusky@7.0.1--save-dev启动hooks，生成.husky文件夹npxhuskyinstall在package.json中生成prepare命令（需要npm>7.0版本）npmset-scriptprepare"huskyinstall"执行prepare命令npmrunprepare执行成功，提示给husky添加commitlinthooks，并在commit-msghooks下指示执行npx--no-installcommitlint--edit"$1"指令npxhuskyadd.husky/commit-msg'npx--no-installcommitlint--edit"$1"'至此，.husky的文件结构到此为止，不符合规范的commit将不再提交：那么我们的标准化目标到此是否完成了？当然不是！现在我们还缺少一个规范的流程，就是代码格式提交规范流程！有的朋友可能会说，哎！为什么这看起来如此熟悉？我们以前不是做过吗？还有什么需要做的？请看下一节分享《标准化编程规范解决方案之代码格式提交规范处理》
