开发工具Lint代码质量【免费下载链接】commitlint Lint commit messages项目地址https://gitcode.com/gh_mirrors/co/commitlint点击查看免费下载在提交信息commit message编写的当下就完成 lint 校验是保证提交信息质量、缩短反馈周期的最直接手段。本指南以 commitlintcommitlint/cli为对象讲解如何通过 git hooks重点是commit-msghook把 lint 接入本地开发流程覆盖 Husky 与原生 git hooks 两种接入方式、npm/yarn/pnpm/bun/deno 各包管理器在 Linux/macOS/Windows 下的完整配置以及 hook 生效后的验证方法与输出行为说明。读完本文你将能在一台全新的开发机上从零配置出一套「提交即校验」的本地 lint 环境并理解其底层实现原理。为什么要在本地做提交信息 lintcommitlint 的核心价值在于把提交信息质量从「靠自觉」变成「可强制」。把 lint 挂在 git hooks 上意味着开发者在git commit时就会被拦截不合格的信息错误在本地、在提交发生前就被发现反馈周期最短不会污染共享历史。本地 lint 适合快速反馈但它有一个天然局限开发者可以轻易绕过本地 hooks例如直接修改.git/hooks目录或使用git commit --no-verify。因此本地 lint 通常与 CI 端的 lint 配合使用——本指南聚焦本地部分CI 侧的方案见 CI Setup 指南。注意commitlint 当前仅支持commit-msghook不支持pre-commithook。因为pre-commit执行时提交信息尚未生成无法拿到待校验的文本。前置准备安装与基础配置在接入 hooks 之前先要完成 commitlint 本体与共享配置的安装。完整步骤见 Getting Started 指南核心两步为安装 CLI 与共享配置以commitlint/config-conventional为例npm install -D commitlint/cli commitlint/config-conventional其他包管理器yarn/pnpm/bun/deno的等价命令见 Getting Started 指南。在项目根目录创建commitlint.config.jsexport default { extends: [commitlint/config-conventional] };这里安装的commitlint/cli即本仓库中的 CLI 包当前版本为21.2.3其bin字段把commitlint命令映射到 cli.js。关于配置文件各字段extends、rules、parserPreset、formatter、helpUrl等的完整说明可查阅 configuration 参考文档 与 rules 参考文档。添加 commit-msg hook方式一使用 Husky 管理 hooksHusky 是社区最常用的 git hooks 管理器它能自动完成 hooks 目录的初始化和可执行权限设置。下文所有命令均针对huskyv9若你使用其他版本请查阅对应版本的官方文档。huskyv9 与 v8 及更低版本在初始化命令上存在差异husky initvshusky install下文会分别给出。npmLinux / macOSnpm install --save-dev husky # huskyv9 npx husky init # huskyv8 or lower npx husky install # 在 commit-msg hook 中加入提交信息 lint echo npx --no -- commitlint --edit \$1 .husky/commit-msg其中npx --no中的--no用于阻止 npx 在本地找不到commitlint时尝试自动安装--edit $1告诉 commitlint 读取 git 传入 hook 的提交信息文件$1是 git 传给commit-msghook 的参数即消息文件路径。--edit未指定文件路径时commitlint 会回退读取./.git/COMMIT_EDITMSG见 cli.ts 中getEditValue的实现。替代方案通过package.jsonscript 包装npm pkg set scripts.commitlintcommitlint --edit echo npm run commitlint \${1} .husky/commit-msg将 lint 命令收敛到package.json的scripts中便于统一管理和复用。yarnyarn add --dev husky # huskyv9 yarn husky init # huskyv8 or lower yarn husky install # 添加 commit message linting 到 commit-msg hook echo yarn commitlint --edit \$1 .husky/commit-msg基于package.jsonscript 的替代方案npm pkg set scripts.commitlintcommitlint --edit echo yarn commitlint \${1} .husky/commit-msg警告当前commitlint/cli不支持 yarn v2 的 PlugnPlayPnP模式。若使用 yarn v2需在.yarnrc.yml中设置nodeLinker: node-modules但官方提示这「有时」可用并不保证稳定。pnpmpnpm add --save-dev husky # huskyv9 pnpm husky init # huskyv8 or lower pnpm husky install # 添加 commit message linting 到 commit-msg hook echo pnpm dlx commitlint --edit \$1 .husky/commit-msg替代方案npm pkg set scripts.commitlintcommitlint --edit echo pnpm commitlint \${1} .husky/commit-msgbunbun add --dev husky # huskyv9 bunx husky init # huskyv8 or lower bunx husky install # 添加 commit message linting 到 commit-msg hook echo bunx commitlint --edit \$1 .husky/commit-msgdenodeno add --dev husky # huskyv9 deno task --eval husky init # huskyv8 or lower deno task --eval husky install # 添加 commit message linting 到 commit-msg hook echo deno task --eval commitlint --edit \$1 .husky/commit-msgWindows 下的等价命令Windows 的 shell 转义规则与 Unix 不同官方建议改用node -e直接写入文件避免编码与转义问题。以 npm 为例npm install --save-dev husky # huskyv9 npx husky init # huskyv8 or lower npx husky install # 添加 commit message linting 到 commit-msg hook node -e fs.writeFileSync(.husky/commit-msg, npx --no -- commitlint --edit $1\n)Windows 下使用 script 的替代方案npm pkg set scripts.commitlintcommitlint --edit node -e fs.writeFileSync(.husky/commit-msg, npm run commitlint ${1}\n)其余包管理器yarn/pnpm/bun/deno在 Windows 下同样使用node -e fs.writeFileSync(...)的形式写入 hook 文件仅替换其中的命令部分yarnyarn commitlint --edit $1\n/yarn commitlint ${1}\npnpmpnpm dlx commitlint --edit $1\n/pnpm commitlint ${1}\nbunbunx commitlint --edit $1\ndenodeno task --eval commitlint --edit $1\n警告同样适用于 Windows 的 yarn 方案commitlint/cli不支持 yarn v2 PlugnPlay请参照前文nodeLinker: node-modules的说明。方式二使用原生 git hooks不依赖任何 hooks 管理器时可直接使用 git 自带的 hooks 机制。git 会在.git/hooks目录下查找以约定名称命名的可执行文件可参考 Git 官方文档中关于 git hooks 的说明其中commit-msghook 会在提交信息编辑器退出后、提交创建前执行。警告hook 文件名必须命名为commit-msggit 只认这个约定名称拼写错误将导致 hook 静默不执行。手动创建原生 hook 的要点# 创建 hooks 目录下的 commit-msg 文件内容同前例如 echo npx --no -- commitlint --edit \$1 .git/hooks/commit-msg chmod x .git/hooks/commit-msg # 需要可执行权限原生 hooks 的缺点是.git目录不参与版本控制无法随仓库分发每个成员都要手动配置而 Husky 会把 hooks 脚本放在仓库内的.husky/目录并自动注册更适合团队协作。验证配置快速测试lint 最近一次提交配置完成后先用一条命令对历史提交做冒烟测试确认 CLI 可用npx commitlint --from HEAD~1 --to HEAD --verbose各包管理器等价命令yarn commitlint --from HEAD~1 --to HEAD --verbose pnpm commitlint --from HEAD~1 --to HEAD --verbose bun commitlint --from HEAD~1 --to HEAD --verbose deno task --eval commitlint --from HEAD~1 --to HEAD --verbose该命令会检查最近一条提交信息不合法时返回错误合法时输出正面结果。--from/--to定义了要 lint 的提交区间--verbose让「没有问题」的报告也输出内容默认情况下无问题时不输出任何东西见下文。不建配置文件的快速体验如果只想先体验 commitlint不想立即创建配置文件可以把消息通过管道喂给它并使用内置的默认配置commitlint/config-conventional即本仓库的 config-conventionalecho feat: add new feature | npx commitlint --default-config--default-config的作用是当配置解析不到任何规则时例如没有配置文件自动回退到内置默认配置一旦存在带规则的配置文件它总是优先于--default-config通过--extends传入的配置也会保留并覆盖默认配置见 cli.ts 中loadConfig的实现。CLI 的完整参数说明可参考 CLI 参考文档。测试 hook 本身最直接的方式就是正常执行一次提交。如果一切正常非法提交会被拦截输出类似git commit -m foo: this will fail # husky commit-msg No staged files match any of provided globs. ⧗ --- input --- foo: this will fail ✖ type must be one of [build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test] [type-enum] ✖ found 1 problems, 0 warnings ⓘ Get help: ... husky - commit-msg script failed (code 1)上面的报错type must be one of [...]来自type-enum规则它是commitlint/config-conventional内置规则之一type-enum配置在 config-conventional 源码 中可查所有可用规则的详细定义见 rules 参考文档。而合法的提交则通过git commit -m chore: lint on commitmsg # husky pre-commit No staged files match any of provided globs. # husky commit-msg输出行为两个值得注意的版本变化自 v8.0.0 起无问题时默认零输出只要提交没有问题commitlint 不打印任何内容上面的成功示例即如此。若希望获得正向反馈可加--verbose标志源码层面见 cli.ts 中format(report, { verbose: flags.verbose, ... })的调用verbose控制无问题报告是否输出。自 v21.0.0 起输入消息的展示位置改变commitlint 会在换行EOL之后输出提交信息而非旧版的冒号之后旧格式为单行input: ...。若需恢复旧版输出格式使用--legacy-output标志。深入原理commitlint 是如何读到提交信息的理解 CLI 的消息来源有助于排查 hook 配置问题。从 cli.ts 的main函数可以看到输入优先级大致如下stdin 管道当--edit、--env、--from、--to都未提供时从标准输入读取checkFromStdin判定。这就是echo ... | npx commitlint能工作的原因历史提交区间--from/--to/--last/--from-last-tag触发从 git 历史读取内部经由commitlint/read包提交信息文件--edit读取指定文件缺省回退./.git/COMMIT_EDITMSG与--env读取环境变量指向的文件。Husky 的commit-msghook 正是把「git 为本次提交生成的临时消息文件路径」通过$1传给commitlint --edit $1commitlint 据此拿到本次待提交的消息文本。cli.ts中还处理了 git 的core.commentChar配置默认#从COMMIT_EDITMSG读取时据此剥离注释行避免把注释当作提交信息参与校验。另外本仓库的 cli.test.ts 中包含多条 husky 集成测试用例例如should work with husky commitmsg hook and git commit、should work with husky via commitlint -e $GIT_PARAMS等它们真实地拉起 git 仓库、写入 hook 并执行提交来验证整个链路对应的测试夹具配置见 fixtures/husky/integration/commitlint.config.js该夹具仅允许foo这一种 type用来演示type-enum规则拦截非法提交。这些测试是理解 hook 工作机制的最佳参考。局限与下一步本地 lint 反馈快、配置简单但它存在两个需要正视的问题可被绕过开发者可以修改本地 hooks 或用--no-verify跳过校验因此本地 lint 无法保证「所有」提交都被检查配置与 hooks 需要随仓库分发团队协作时Husky 的.husky/目录、package.json脚本应纳入版本控制才能保证每个成员行为一致。要确保所有提交包括被本地跳过的都被 lint需要在 CI 服务器上再次校验。关于 CI 端的接入方式请继续阅读 CI Setup 指南关于完整配置能力规则覆盖、parser 自定义、插件、formatter 等可进一步查阅 configuration 参考文档。赞分享开发工具Lint代码质量【免费下载链接】commitlint Lint commit messages项目地址https://gitcode.com/gh_mirrors/co/commitlint点击查看免费下载相关推荐commitlint与Git Hooks深入理解提交前校验的终极指南commitlint与Git Hooks深入理解提交前校验的终极指南 在软件开发过程中 commitlint 作为一款强大的提交信息校验工具通过与Git开发工具Lint代码质量BNB Smart Chain 提交信息规范读懂 docs/lint/commit.md 与 commitlint 落地实践BNB Smart Chain 提交信息规范读懂 docs/lint/commit.md 与 commitlint 落地实践 本文是 BSCBNB Smar区块链Web3使用 commitlint/config-angular 以 Angular 提交规范约束 Git 提交信息使用 commitlint/config angular 以 Angular 提交规范约束 Git 提交信息 commitlint/config angul开发工具Lint代码质量上一篇终极指南如何构建最小化的Stable Diffusion WebUI Docker镜像下一篇如何快速解决Upscayl AI图像超分工具的Vulkan兼容性问题5个实用技巧创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考