如何配置Git提交代码检查？

一起来看看gitcommit时如何使用commitlint+Husky规范提交信息吧！1.基本概述在多人协作团队中，标准化的提交信息更具可读性和查找性。每个人的gitcommit信息都不一样，没有机制很难保证标准化。而commitlint可以帮我们解决这个问题。Commitlint是一种自动化工具，用于检查提交约定并在不符合规范时拒绝提交。当然，这些规则是可配置的。使用commitlint的优点：自动变更日志：由于提交遵循标准约定，可以使用标准版本等工具自动生成变更日志；更好地理解commit：特定类型和范围的commit将帮助我们了解commit更改了哪些代码；遵守特定约定：在多人协作的大型项目中，commitlint可以防止非标准提交，从而使commit遵循定义惯例。Git允许开发人员在触发特定事件时执行一些操作，这称为githook。我们可以在git工作流的很多阶段进行操作，比如：pre-commitpre-pushpre-rebasepost-update但是这个需要在本地.git文件中配置，所以默认情况下，每个开发者都需要安装需要的Hooks所以可以执行特定的检查。幸运的是，Husky可以帮助我们解决这个问题，而Husky可以让我们轻松地为项目添加githooks。Husky不仅可以用于执行提交约定，还可以在提交时运行静态代码分析、测试、自动代码格式化等。所以我们可以使用Husky和commitlint来检查commit信息是否符合commit规范。2、安装配置由于Commitlint使用的是Husky，所以我们需要先安装它。Husky是作为开发依赖项提供的，因此它仅在本地使用，不与生产代码捆绑在一起。在终端执行以下命令安装Husky：//使用npm安装npminstall--save-devhusky//使用yarn安装yarnaddhusky--dev现在我们需要定义一个Hook来检查commit信息，这个钩子叫做commit-msg需要在package.json中定义："husky":{"hooks":{"commit-msg":"commitlint-EHUSKY_GIT_PARAMS"}}或者，我们也可以定义一个.huskyrc配置在项目根目录下的文件中，在这个配置文件中单独定义Husky配置：{"hooks":{"commit-msg":"commitlint-EHUSKY_GIT_PARAMS"}}这段代码告诉githooks，当我们执行gitcommit-m'message'会触发commit-msg事件钩子，通知husky执行commitlint-e$GIT_PARAMS命令。该命令会读取commitlint.config.js中配置的规则，并验证提交的信息。如果验证失败，将在终端输出错误并终止提交。使用Husky，下一步是安装CommitlintCLI，它将由Husky钩子执行以验证提交消息：//Installwithnpmnpminstall--save-dev@commitlint/cli//Installwithyarnyarnadd@commitlint/cli--devCommitlint只是一个用于检查提交消息是否符合规范的工具。所以，我们还需要一个提交规范。这个配置是完全可定制的，当然，Commitlint提供了一些超出当前支持的配置的配置：@commitlint/config-conventional@commitlint/config-lerna-scopes@commitlint/config-patternplate@commitlint/config-angular@commitlint/config-angular-type-enumCommitlint推荐使用config-conventional配置规范commit，安装命令如下：//使用npm安装npminstall--save-dev@commitlint/config-conventional//使用yarn安装yarnadd@commitlint/config-conventional--dev在最后一步，我们需要创建一个Commitlint配置文件，在这个配置文件中我们可以定义要使用的配置，也就是上面刚刚安装的配置规范。你只需要在项目的根目录下创建一个名为commitlint.config.js的规范：module.exports={extends:['@commitlint/config-conventional'],};这样就完成了Husky和Commitlint配置的安装和安装。其执行过程如下：3.Commitlint推荐使用config-常规配置，其提交格式如下：gitcommit-m[optionalscope]:一共有三个参数：type:required，表示submission变更类型；optionalscope：可选，表示提交修改的范围，需要用括号括起来；description：必填，表示对提交内容的描述。常见类型类型如下：build：影响构建组件的变更，如构建工具、依赖、项目版本等；chore：构建流程、辅助工具等变更。ci：持续集成的变更；文档：影响文档的更改。壮举：引入新功能的更改。修复：修复错误的更改。perf：与优化有关，比如提升性能和体验。重构：代码重构的更改。还原：还原以前提交的更改。样式：代码格式的更改（空格、格式、缺少分号等）。测试：添加缺失测试或更正现有测试的更改。例如：gitcommit-m'feat:addxxxfunction'gitcommit-m'feat(xxmodule):addyyyfunction'gitcommit-m'fix:fix:fixxxxproblem'下面是git提交信息的例子：查看config-conventional配置是如何定义的：module.exports={parserPreset:'conventional-changelog-conventionalcommits',rules:{'body-leading-blank':[1,'always'],'body-max-line-length':[2,'always',100],'footer-leading-blank':[1,'always'],'footer-max-line-length':[2,'always',100],'header-max-length':[2,'always',100],'scope-case':[2,'always','lower-case'],'subject-case':[2,'never',['sentence-case','start-case','pascal-case','upper-case'],],'subject-empty':[2,'never'],'subject-full-stop':[2,'never','.'],'type-case':[2,'always','lower-case'],'type-empty':[2,'never'],'type-enum':[2,'always',['build','chore','ci','docs','feat','fix','perf','refactor','revert','style'，'测试'，]，]，}，};这里包含了很多配置项，这些配置项由配置名和配置数组组成，数组的第一个元素是level，可选值0、1、2，0为disable，1为warning，2为error，第二个元素为是否应用，可选值为always，never，第三个元素为配置规则以上是config-conventional默认规则，我们可以在commitlint.config.js配置文件中覆盖这些规则：module.exports={extends:['@commitlint/config-conventional'],rules:{'scope-case':[0,'never'],'header-max-length':[0,'always',120]}};