引言
Git Husky 与 Commitlint 是两个在 Git 工作流程中非常实用的工具，它们可以帮助团队维护代码质量和提交规范。Husky 是一个 Git 钩子管理器，允许你在仓库级别方便地配置钩子脚本；而 Commitlint 则是用来规范 Git 提交信息的工具，确保每次提交都遵循一定的格式标准。下面是一个关于如何使用这两个工具的简明教程，以及如何进行基本配置。
使用 Husky 和 Commitlit 的版本
"husky": "^9.0.11", "@commitlint/cli": "^19.3.0", "@commitlint/config-conventional": "^19.2.2",
安装 Husky 和 Commitlint
首先，你需要在项目中安装 Husky 和 Commitlint，以及 Commitlint 的一个预设规则库（如 @commitlint/config-conventional）来定义提交信息的格式规范。
npm install --save-dev husky @commitlint/cli @commitlint/config-conventional
配置 Husky
接下来，配置 Husky 以便在 git commit 命令执行前自动运行 Commitlint 检查。
init 命令简化了项目中的 husky 设置。它会在 .husky/ 中创建 pre-commit 脚本，并更新 package.json 中的 prepare 脚本。随后可根据你的工作流进行修改。
pnpm exec husky init
执行后的效果如下：
package.json 文件中 script 新增一行脚本：
配置 Commitlint
Commitlint 需要一个配置文件来定义提交信息的规则。通常这个文件名为 commitlint.config.js 或 .commitlintrc.json，位于项目根目录。这里我们使用 JavaScript 配置文件作为示例：
// .commitlint.config.js
export default {
extends: ['@commitlint/config-conventional'],
rules: {
'type-enum': [
2,
'always',
[
'bug', // 此项特别针对bug号，用于向测试反馈bug列表的bug修改情况
'feat', // 新功能（feature）
'fix', // 修补bug
'docs', // 文档（documentation）
'style', // 格式（不影响代码运行的变动）
'refactor', // 重构（即不是新增功能，也不是修改bug的代码变动）
'test', // 增加测试
'chore', // 构建过程或辅助工具的变动
'revert', // feat(pencil): add ‘graphiteWidth’ option (撤销之前的commit)
'merge' // 合并分支， 例如： merge（前端页面）： feature-xxxx修改线程地址
]
]
}
}
在这个配置中，我们继承了 @commitlint/config-conventional 的默认规则，并可以自定义一些规则来满足特定项目需求。
添加 commit-msg 钩子，提交时自动检测提交信息
在 .husky 目录下新建文件且没有后缀，名字是： commit-msg
pnpm dlx commitlint --edit $1 # $1 表示传递的第一个参数
实践提交
现在，当你尝试执行 git commit 时，Husky 会触发 Commitlint 对你的提交信息进行检查。如果格式不正确，它会给出错误信息并要求你修改。
- 正确的提交信息应该是这样的：
git commit -m "fix: 修复页面的样式问题"
其中，“fix”是提交类型的简短描述，冒号后紧跟空格和对本次提交的详细描述。
- 错误的提交信息如下：
git commit -m "新增 husky commitlit"
不出意外的话，将会报如下错误，并且提交中断
> husky-vue3-template@0.0.0 format G:\wokespace\github\husky-vue3-template > eslint . --ext .vue,.js,.jsx,.cjs,.mjs,.ts,.tsx,.cts,.mts --fix --ignore-path .gitignore .../packages/pnpm/store/v3/tmp/dlx-4288 | Progress: resolved 1, reused 0, downloaded 0, added 0 .../packages/pnpm/store/v3/tmp/dlx-4288 | Progress: resolved 114, reused 95, downloaded 0, added 0 .../packages/pnpm/store/v3/tmp/dlx-4288 | Progress: resolved 124, reused 124, downloaded 0, added 0 .../packages/pnpm/store/v3/tmp/dlx-4288 | +125 +++++++++++++ .../packages/pnpm/store/v3/tmp/dlx-4288 | Progress: resolved 125, reused 125, downloaded 0, added 29 .../packages/pnpm/store/v3/tmp/dlx-4288 | Progress: resolved 125, reused 125, downloaded 0, added 30 .../packages/pnpm/store/v3/tmp/dlx-4288 | Progress: resolved 125, reused 125, downloaded 0, added 115 .../packages/pnpm/store/v3/tmp/dlx-4288 | Progress: resolved 125, reused 125, downloaded 0, added 116 .../packages/pnpm/store/v3/tmp/dlx-4288 | Progress: resolved 125, reused 125, downloaded 0, added 125, done ⧗ input: 新增 husky commitlit ✖ subject may not be empty [subject-empty] ✖ type may not be empty [type-empty] ✖ found 2 problems, 0 warnings ⓘ Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint .......
总结
通过结合 Husky 和 Commitlint，你可以有效地提高代码仓库的管理效率，确保每个提交都遵循一致的格式和高质量标准。这不仅有利于团队成员之间的沟通，也有助于自动化工具更好地理解和处理提交历史。希望这篇教程能帮助你顺利地在项目中应用这两个强大的工具。
关于工作流工具的内容已经说完了，但是我还想说点别的，主要想说一下我们应该学习哪些技术才能让它更加保值。
在我看来，越偏向于业务的技术越不容易过时，为什么呢？需求在变，技术一直在变，业务也一直在迭代。前端技术的发展非常快，也涌现出很多的框架（例如 HTML4 到 HTML5 的升级，或者从jQuery 到前端三大框架的转变），但是总归就是两个字：效率。
作为开发者，我们需要保持好奇心和学习热情，不断探索新的技术，只有这样，我们才能在这个快速发展的时代中立于不败之地。介绍一款程序员都应该知道的软件JNPF快速开发平台，很多人都尝试用过它，它是功能的集大成者，任何信息化系统都可以基于它开发出来。
JNPF可以实现应用从创建、配置、开发、测试到发布、运维、升级等完整生命周期的管理。减少了传统应用程序的代码编写量，通过图形化、可视化的界面，以拖放组件的方式，即可快速生成应用程序的产品，大幅降低了开发企业管理类软件的难度。
当然，我更建议大家成为一个全栈，不要把自己的定位局限于前端。
