提交类型到版本号的映射是什么
约定式提交规范把提交类型与语义化版本对应起来：fix 对应补丁位、feat 对应次版本位、破坏性变更对应主版本位，其余类型通常只进变更日志、不触发版本变化。自动发版工具（如 semantic-release、standard-version）正是按这条映射决定下一个版本号，因此提交类型写得准确与否，直接决定了发布的版本是否正确，也省掉了人工拍版本号这一步。
基本信息
| fix | 对应 PATCH 位，如 1.4.2 → 1.4.3 |
|---|---|
| feat | 对应 MINOR 位，如 1.4.3 → 1.5.0 |
| 破坏性变更 | 对应 MAJOR 位，如 1.5.0 → 2.0.0 |
| 其余类型 | 通常不触发版本变化 |
| 平台 | 由提交信息驱动，与托管平台无关 |
典型使用场景
- 用自动发版工具决定下一个版本号
- 人工核对本次发版应该升哪一位
- 排查版本号跳变异常，回看提交类型是否写错
- 实现从提交到变更日志再到标签的自动化链路
- 0.x 阶段明确团队对版本升级的约定
- 发布前复核本区间提交前缀是否与预期一致
映射关系
| 提交内容 | 版本位 | 示例 |
|---|---|---|
| fix: … | PATCH | 1.4.2 → 1.4.3 |
| feat: … | MINOR | 1.4.3 → 1.5.0 |
| BREAKING CHANGE 或 ! | MAJOR | 1.5.0 → 2.0.0 |
| docs/test/chore 等 | 通常不触发 | 仅进变更日志 |
人工核对
人工核对
git log --oneline v1.4.2..HEAD # 看本区间全部提交
git log --oneline --grep '^feat' v1.4.2..HEAD # 找次版本变更
git log --oneline --grep '^fix' v1.4.2..HEAD # 找补丁变更
git log --oneline --grep 'BREAKING CHANGE' v1.4.2..HEAD自动版本工具都基于同一映射；0.x 阶段是否放宽为次版本升级，需要在团队规范中明确，否则不同工具的行为会被误判为缺陷。
映射只适用于能被识别的提交：类型拼写错误或标题格式不合规的提交会被工具忽略，版本号也就不会随它变化。
发版前的核对清单
- 确认区间两个端点标签都存在且指向正确
- 按类型分组核对提交前缀，重点找漏标的破坏性变更
- 确认 0.x 阶段的升级约定与本次判断一致
- 生成版本号后回看变更日志，确认没有遗漏用户可见改动