在 《JS 模块化》系列开篇中，曾提到前端技术的发展不断融入很多后端思想，形成前端的“四个现代化”：工程化、模块化、规范化、流程化。在该系列文章中已详细介绍了模块化的发展及四种模块化规范。本文简单聊聊规范化中的 git 规范。
1 规范化
在企业级开发中，“一千个读者有一千个哈姆雷特”是很常见的事，每个程序员对技术的理解、视角和掌握程度参差不齐，导致编写的代码五花八门。规范化包括很多，我在企业实践中重点关注两个方面：代码规范 和 git 提交规范。
代码规范最基础的是代码格式，不同的代码格式虽然运行起来没有问题，但代码超级难看，代码乱七八糟、一堆 warning，虽然不影响运行，但看着太恶心，就像下面的情形：
- 估计是为了节省纸张，空格全省略，代码全挤在一起：
const a=b+c
const fn=()=>{}
fn(){}
for(let i=0; i<10; i++){}
- 单引号、双引号混合使用，上一行用单引号，下一行偏要用双引号；
- 上一行加分号，后一行省略分号；
- 定义了一些从没有使用的变量；
- 分支判断中只有一句话坚决不写花括号；
- ......
我不能说上面的风格是错误的（写代码就像玩音乐一样，不能说绝对的对错，只是理解不同罢了），无论怎么写，至少一个团队还是应该保证统一的风格吧。于是咱们就使用了 .editorconfig 和 eslint。
.editorconfig 对编辑器的基本格式做了限制，但比较粗糙；eslint 就进行了详细的约束。无论选择 standard 、airbnb、prettier 任何一种，都是为了强制团队使用统一的代码风格。
在 《创建 vite vue3 项目》一文中已讨论了如何在基于 vite 的 vue3 项目中如何整合 eslint。
本文重点讨论 git 提交规范。
2 git 提交规范
大家应该都是使用 git 管理代码吧？如果你在企业还是使用 SVN 管理代码，那可以赶快跑路了。git 提交代码使用 git commit -m '描述' 命令。但描述信息很多情况下都是随意填写，git 提交规范就是针对这个描述信息的约束。
2.1 Angular 规范
Angular 团队规范是目前使用较多的 git 提交规范 —— 约定式提交。规范要求提交的描述信息格式为：
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
含有 optional 表示可选，故必填的内容是 type 和 description。
type 表示这次提交的类型，包括如下值：
| type | 含义 |
|---|---|
| feat | 新功能 |
| fix | 修复 |
| docs | 文档变更 |
| style | 代码格式（不影响代码运行） |
| refactor | 重构（不增加新功能，也不是修改 bug） |
| perf | 性能优化 |
| test | 添加测试 |
| chore | 修改构建过程或辅助工具 |
| revert | 回退 |
| build | 打包 |
例如，实现了一个修改用户列表功能，此时提交代码使用如下命令：
git commit -m 'feat: 实现用户列表'
修改了 vite.config.ts 的配置，压缩打包文件：
git commit -m 'chore: 修改vite生产配置'
2.2 Commitizen
确定了git 提交时描述信息的规范，那如何让人遵守执行呢？首先需要让开发同事知道提交信息的内容，此时可以使用工具 commitizen 来完成。commitizen 是一个 git 提交规范化的工具，提供了 git cz 命令来代替传统的 git commit 命令。使用 git cz 来提交代码，commitizen 会一步步提示输入的字段，并提交所填写的必需字段。换句话说，使用 git cz 命令，底层最后会执行 git commit，但在执行 git commit 前，会校验描述信息是否符合规范。如果不符合规范，则不会执行 git commit，提交失败。
- 全局安装 commitizen
yarn global add commitizen
- 在工程中安装 cz-conventional-changelog
yarn add cz-conventional-changelog -D
- 在工程中初始化 commitizen 的约定式提交：
commitizen init cz-conventional-changelog --yarn --dev --exact
执行完该命令，package.json 文件中会自动生成如下配置：
"config": {
"commitizen": {
"path": "./node_modules/cz-conventional-changelog"
}
}
完成上述步骤后，便可以使用 git cz 命令来提交代码了。
添加需要提交的文件，添加文件后执行 git cz 命令，提示如下：
使用上下键选择提交的类型，按照提示输入相关内容或必填内容即可完成提交。
3 git hooks
上面实现了 Git 提交规范，但仍然有不听话的同学会使用 git commit，如此一来提交信息依旧是乱七八糟的，此时便需要使用 git hooks 了。
3.1 什么是 git hooks
hooks 意思是“钩子”，也就是在执行某个操作之前或之后要做的事。git hooks 就是 git 操作的钩子，在 git 执行某个操作之前或之后要做的事，如 git 提交后、提交后、合并前、合并后、rebase前、rebase后等。在这里需要重点关注的 git 钩子有两个：
- pre-commit
pre-commit 是 git commit 执行前的钩子，会在获取提交描述信息且提交前被调用，根据该钩子决定是否拒绝提交。可以在这个钩子中对代码进行 eslint 检查。
- commit-msg
commit-msg 也是 git commit 执行前的钩子，用来规范化标准格式，根据标准和提交的描述信息决定是否拒绝提交。可以在这个钩子中检查提价信息是否符合规范。
3.2 commitlint 和 husky
理解 git hooks 后，就是如何在工程中引入上述钩子。此时需要使用到 husky 和 commitlint。两者结合起来可以在提交的描述信息不规范时会导致提交失败，并提示错误。首先安装配置 commitlint。
- 安装 husky 和 commitlink 相关依赖：
yarn add husky @commitlint/cli @commitlint/config-conventional -D
- 在项目根目录创建 commitlint.config.cjs 配置文件：
module.exports = {
extends: [
'@commitlint/config-conventional'
]
}
- 初始化 husky
npx husky install
执行完成后，项目根目录会自动生成一个 .husky 文件夹。
3.3 pre-commit 和 commit-msg 钩子
接下来需要使用 lint-staged 对git 暂存区（git add . 的内容）文件进行 eslint 检查。
- 安装 lint-staged
yarn add lint-staged -D
- 在 package.json 中添加 scripts：
"scripts": {
...
"lint": "eslint \"src/**/*.{js,ts,vue,jsx,tsx}\" --fix"
},
- 在 package.json 添加 lint-staged 配置：
{
.....
"lint-staged": {
"*.{js,ts,jsx,tsx,vue}": [
"npm run lint"
]
}
}
- 分别执行下列命令，为 husky 添加 commit 前的 hook，让其执行 eslint 和 commitlint ：
npx husky add .husky/pre-commit 'npx lint-staged'
npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'
执行完该命令后，会自动在 .husky/ 目录下生成 pre-commi 文件和 commit-msg 文件。
pre-commit 文件内容如下：
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"
npx lint-staged
commit-msg 文件内容如下：
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"
npx --no-install commitlint --edit ""
3.4 测试
到此为止便完成了配置，可以按如下步骤进行测试：
git add .
git commit -m '测试提交'
控制台会出现如下错误提示：
使用 git cz 命令重新提交，便可以成功提交。
各位还可以弄点 eslint 错误再提交试试效果。
标签：Git,--,Hooks,代码,git,提交,husky,commit,vite From： https://www.cnblogs.com/youyacoder/p/16791663.html