提交类型是什么
Conventional Commits 约定提交标题形如 type(scope): description，其中 type 说明这次改动属于哪一类。规范层面只强制 feat 与 fix 两种核心类型，其余 build、chore、ci、docs、style、refactor、perf、test 等来自 Angular 团队的约定与社区实践。类型集合由团队自行裁剪，但必须写进贡献指南并保持一致，它也是自动生成变更日志与决定版本号的输入。
基本信息
| 标题格式 | <type>(<scope>): <描述>，scope 可省略 |
|---|---|
| 规范强制 | feat 与 fix |
| 社区扩展 | build / chore / ci / docs / style / refactor / perf / test 等 |
| 破坏性标记 | type 后加 ! 或页脚写 BREAKING CHANGE |
| 平台 | 与托管平台无关，写进提交信息即可 |
常用 type
| type | 含义 | 示例场景 |
|---|---|---|
| feat | 新增功能 | 新接口、新页面 |
| fix | 缺陷修复 | 修复空指针、纠正计算 |
| docs | 文档变更 | README、注释 |
| refactor | 重构，行为不变 | 抽函数、换实现 |
| perf | 性能优化 | 减少查询次数 |
| test | 测试相关 | 补用例、改夹具 |
| build | 构建与依赖 | 升级依赖、改打包 |
| ci | 流水线配置 | 改工作流文件 |
| chore | 杂项维护 | 版本号、脚本调整 |
使用要点
- 描述用动词开头说清做了什么，类型本身只表达改动性质
- 一次提交只做一类事，混在一起会让类型判断失真
- scope 建议写模块或目录名，便于按区域检索历史
- 允许的类型越少越好用，超过十个前缀团队就开始随意挑
- 改了行为就归 fix，没改行为才是 refactor，边界写进指南
- 紧跟冒号与一个空格再接描述，格式统一才方便工具解析
使用示例
使用示例
git commit -m 'feat(cart): 支持优惠券叠加'
git commit -m 'fix(login): 修复重定向循环'
git commit -m 'docs: 补充部署前置条件'
git commit -m 'refactor(core): 提取重试工具函数'
git commit -m 'perf(db): 批量写入替代逐条插入'
git commit -m 'test(order): 补充超时用例'类型清单写进仓库的 CONTRIBUTING，并明确允许集合与边界示例，能显著减少语义相近的前缀各自为政；类型名建议统一小写以保持一致。
类型还决定自动化行为：规范把 fix 映射为补丁版本、feat 映射为次版本，破坏性变更映射为主版本；类型写错会让发版工具算错版本，提交前值得多看一眼。
一个提交长什么样
- 首行：type(scope): 一句话说明
- 空行分隔正文
- 正文：为什么这样改、有什么取舍（可选，但对回溯很有帮助）
- 页脚：关联单号如 Closes #123、破坏性变更说明（按需）