提交消息规范检查器

问题：为什么提交消息需要结构化？

当团队协作时，随意的提交消息会导致三个典型问题：

• 变更追溯困难：fix bug 这类模糊描述无法快速定位问题根源
• 日志生成受阻：自动生成 CHANGELOG 需要标准化的 type 标识（如 feat:、fix:）
• 代码审查低效：非结构化消息使 reviewer 难以通过 git blame 追溯修改意图

核心机制：从规则定义到自动拦截

commitlint 通过三层机制解决问题：

1. 规则定义层：基于 Conventional Commits 规范定义 type(scope): subject 格式，强制字段位置（如 type 必须在开头）
2. 配置共享层：通过 npm 包发布团队规范配置（如 @team/commitlint-config），成员本地安装即可统一规则
3. 自动拦截层：与 husky 集成后，在 pre-commit 和 commit-msg 阶段自动触发校验，不合规提交直接阻断

适用边界：何时应该引入 commitlint？

• 适用场景：

- 需要自动化生成版本日志的敏捷团队
- 使用 git hooks 强化代码质量管控的技术团队
- 多语言项目（Java/Go/Rust 等）需统一提交规范

• 注意点：

- 需同步维护配置包版本（建议使用 workspace:* 依赖管理）
- 强制约束可能降低提交速度（建议初期配合 --no-verify 过渡）
- 历史提交消息需通过 git commit --amend 逐步修正