约定式提交是什么
提交信息采用「类型(范围): 描述」的机器可解析格式：据此生成变更日志、推断语义化版本、驱动自动化发布。约定本身很轻，靠工具落地：commitlint 在提交或 CI 阶段校验格式，semantic-release、release-please 等工具消费提交生成版本号与发布说明。破坏性变更用类型后的感叹号或页脚 BREAKING CHANGE 显式标注，发布工具据此把主版本号加一。
基本信息
| 格式 | type(scope): subject |
|---|---|
| 常用类型 | feat、fix、docs、chore、refactor、perf、test、ci、build |
| 版本语义 | feat 对应次版本、fix 对应修订号（配合发布工具生效） |
| 破坏性变更 | 类型后加感叹号或页脚 BREAKING CHANGE |
| 常用工具 | commitlint 校验、semantic-release、release-please |
| 落地位置 | 本地钩子与 CI 双重校验，防止绕过 |
典型使用场景
- 自动生成变更日志：按类型分组，输出用户能读懂的发布说明
- 版本号自动化：从提交推断下一版本，不再手工决定
- 发布流水线触发：合并主干后自动打标签与发布
- 评审效率：提交按类型归类，评审人快速判断变更性质
- 变更审计：按类型检索提交，定位「什么时候引入的那次修复」
- 新人友好：模板与校验让新人第一次提交就符合约定
提交示例
提交示例
feat(api): 支持批量导入订单
fix(cart): 修复优惠券重复计算
docs: 更新部署说明
refactor(core)!: 重写配置加载 # 感叹号表示破坏性变更
BREAKING CHANGE: 删除旧版接口 /v1/orders类型与版本影响
| 类型 | 含义 | 版本影响 |
|---|---|---|
| feat | 新功能 | 次版本号加一 |
| fix | 缺陷修复 | 修订号加一 |
| docs / chore / ci | 文档与流程杂项 | 通常不产生新版本 |
| 带感叹号或 BREAKING CHANGE | 破坏性变更 | 主版本号加一 |
格式校验交给 commitlint、版本与日志交给发布工具：约定才能从纸面落到流程。
仓库启用压缩合并时要配置标题模板：否则压缩后的提交信息可能不符合格式，校验直接失败。
提交格式与发布策略分工：格式管信息规范，发不发版本由发布工具的策略决定。