为什么需要提交规范
团队提交历史常常变成一团乱麻：fix bug、update、改了一下。这类信息对半年后的你毫无价值。好的提交信息应当回答两个问题：
- 改了什么（what）
- 为什么改（why）
提交规范的价值在于：机器可解析、人类可读、能自动生成 CHANGELOG、能推导语义化版本号。
Conventional Commits 规范
格式如下：
<type>(<scope>): <subject>
<body>
<footer>type：提交类型（见下表）scope：可选，影响范围（模块/组件）subject：简短描述，祈使句、不加句号、不超过 50 字body/footer：可选，说明动机与破坏性变更
常用 type
| type | 含义 |
|---|---|
| feat | 新功能 |
| fix | 修复 bug |
| docs | 文档变更 |
| style | 格式（不影响逻辑） |
| refactor | 重构 |
| perf | 性能优化 |
| test | 测试 |
| chore | 构建/依赖等杂项 |
| revert | 回滚 |
示例
feat(auth): 支持 OAuth2 第三方登录
新增 Google / GitHub 登录入口，用户信息通过 JWT 下发。
BREAKING CHANGE: 旧的 session 鉴权接口已下线。带 BREAKING CHANGE: 的提交会被工具识别为破坏性变更，发布时升主版本号。
用 commitlint + husky 自动校验
光靠自觉不够，用工具在提交前拦下来。先在项目里加 commitlint.config.js：
module.exports = {
extends: ['@commitlint/config-conventional'],
}再用 husky 挂一个 commit-msg 钩子：
npx husky add .husky/commit-msg "npx --no-install commitlint --edit $1"此后不符合规范的提交会被直接拒绝，并提示正确格式。
从提交推导版本号
有了结构化提交，可以用 standard-version 或 semantic-release 自动：
fix→ 升 patch（1.0.0 → 1.0.1）feat→ 升 minor（1.0.0 → 1.1.0）BREAKING CHANGE→ 升 major（1.0.0 → 2.0.0）
同时自动生成 CHANGELOG，无需手工维护。
规范不是束缚，而是给未来的自己和协作者留的一份地图。