写点什么

现代前端工程化实践:Git、Husky、Commitlint 与 PNPM 的协同作战

作者:秃头小帅oi
  • 2024-05-21
    福建
  • 本文字数:2474 字

    阅读完需:约 8 分钟

现代前端工程化实践:Git、Husky、Commitlint与PNPM的协同作战

引言

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 可以实现应用从创建、配置、开发、测试到发布、运维、升级等完整生命周期的管理。减少了传统应用程序的代码编写量,通过图形化、可视化的界面,以拖放组件的方式,即可快速生成应用程序的产品,大幅降低了开发企业管理类软件的难度。

当然,我更建议大家成为一个全栈,不要把自己的定位局限于前端。

用户头像

摸个鱼,顺便发点有用的东西 2023-06-19 加入

互联网某厂人(重生版)

评论

发布
暂无评论
现代前端工程化实践:Git、Husky、Commitlint与PNPM的协同作战_秃头小帅oi_InfoQ写作社区