团队项目中可以从你的commit记录看到你的动作信息，规范提交必须按照如下格式（避免有人出现这样的提交 git commit -m “update”）
feat：新功能（featuer）fix:修补bug docs： 文档（documentation） perf：性能优化 style：格式（修改样式，不影响代码运行的变动） refactor：重构（既不是新增功能，也不是修改bug的代码变动） chore：构建过程或辅助工具的变动 revert：撤销，版本回退 test：测试 improvement：改进 build：打包 ci：持续集成可以自己写命令完成对commit信息的校验，当然也可以借助第三方工具库
以下是工具库的方法
第一步：
npm install-Dcommitlint @commitlint/config-conventional @commitlint/cli第二步（项目根目录新建这个文件，文件内容如下）：
.commitlintrc
{"extends":["@commitlint/config-conventional"]}这个工具库对应的规则是怎样的？
既然你使用了 @commitlint/config-conventional，那么你的提交记录必须遵循 Conventional Commits（约定式提交） 规范。
这种格式目前是社区（如 Angular、Vue、React）最通用的标准。一个规范的提交信息结构如下：
<type>(<scope>): <description>- 核心字段详解
Type（必需） 用于说明本次提交的类型。常用类型包括： feat: 引入新功能（feature）。 fix: 修复 Bug。 docs: 仅修改文档（如 README）。 style: 格式化修改（不影响代码运行，如空格、分号等）。 refactor: 代码重构（既不是修复 Bug 也不是加新功能）。 perf: 提高性能的代码更改。 test: 添加或修改测试用例。 chore: 构建过程、辅助工具或依赖库的变动（如更新 npm 包）。 revert: 撤销之前的提交。 Scope（可选） 说明影响的范围。例如：feat(auth):、fix(header):。 Description（必需） 对变动的简短描述。 规则：首字母通常小写，结尾不加句号（.）。 4. 正确示例 ✅ feat: add login functionality（基础） fix(api): handle unauthorized error（带作用域） docs: update installation steps（文档） chore: update husky to v9（依赖更新） 5. 错误示例 ❌（会导致 commit 失败） Fixed the bug（缺少 type 类型） feat:Add login（冒号后缺少空格） update code（格式完全不对）💡 进阶建议：使用 commitizen
如果你觉得手动输入这些格式太麻烦，可以安装 commitizen。它会通过问答的方式帮你生成符合规范的提交信息：
安装：npm install -D commitizen cz-conventional-changelog
在 package.json 中配置：
``
“scripts”: {
“commit”: “cz”
}
第三步：将提交的信息验证也通过husky进行管理了（代码意思：在提交信息的时候执行 提交信息验证） ```javascript npx husky add .husky/commit-msg 'npx --no -- commitlint --edit ${1}'验证一把是否生效：
