一、引言：你的提交记录还在"裸奔"吗？
先来看一段真实的、令人头疼的提交历史：
* 修复bug
* 更新
* asdasd
* 来点新功能
* 改了点东西
* 再改改
如果你是新加入项目的成员，看到这样的记录会作何感想？你完全不知道"修复bug"修的是哪个bug，"更新"更新了什么，"再改改"到底改了啥。这样的提交历史几乎等于没有记录。
这样的提交信息会带来一堆麻烦：
- 无法快速定位问题：出了线上事故想回溯，一条条点开看代码差异，效率极低。
- 无法自动生成日志：想给项目做个版本更新日志（CHANGELOG）？只能一条条手写，费时费力。
- 团队协作困难：别人接手你的代码时，看不懂你每次都改了什么性质的东西。
有没有一种方法，能让提交信息既清晰又有规律，甚至还能被机器读懂、自动帮我们干活？
有，它就是本文的主角——约定式提交（Conventional Commits）。
接下来，我会用最通俗的语言讲清楚它是什么、格式长什么样，并且用大量"什么场景该用什么前缀"的实战示例，让你读完就能立刻上手。
二、什么是约定式提交？
2.1 一句话解释
约定式提交是一种给提交信息定规矩的轻量级约定，让每一次 git commit 都"说人话"且"有规律"。
说白了，它就是一套大家约定俗成的书写格式：每条提交信息开头先用一个固定的"类型词"标明这次改动的性质（比如新功能、修bug），然后再简短说明做了什么。规则很少，几分钟就能学会。
2.2 为什么需要它？
遵守这套约定，你能得到实打实的好处：
- 好处一：提交历史一目了然。 团队成员一看开头的类型词，立刻就知道这次是加了功能、修了bug还是改了文档，不用再逐个点开看代码。
- 好处二：可以自动生成 CHANGELOG。 因为格式统一，工具能自动扫描所有提交，把新功能、修复项分类整理成一份漂亮的更新日志，你不用再手写。
- 好处三：能配合语义化版本自动升级版本号。 约定式提交和语义化版本（SemVer）天然契合。通过识别提交里是新功能（feat）、修复（fix）还是破坏性变更（BREAKING CHANGE），工具可以自动判断该发布大版本、小版本还是补丁版本。
打个比方：这就像你发邮件时会给邮件加上分类标签（工作 / 生活 / 紧急）一样。有了标签，你一眼就能分清轻重缓急。提交信息也是同样的道理，加上"分类标签"后，整个项目历史立刻变得井井有条。
三、约定式提交的基本格式
3.1 标准格式长这样
一条完整的约定式提交，结构是这样的：
<类型>[可选 范围]: <描述>
[可选 正文]
[可选 脚注]
看起来有点多？别慌，日常开发中最常用的其实只有第一行。我们逐个拆开看。
3.2 逐部分拆解
- 类型（必填）：一个单词，说明"这是什么性质的改动"，比如
feat（新功能）、fix（修bug）。类型后面紧跟一个英文半角冒号和一个空格。 - 范围（可选）：说明这次改动影响的具体模块，写在类型后面的圆括号里，比如
feat(login)表示这个新功能是关于登录模块的。不写也没关系。 - 描述（必填）：紧跟在冒号和空格之后，用一句话简短总结你做了什么。
3.3 一个完整示例拆解
来看这条提交：
feat(login): 新增手机号验证码登录功能
把它拆开对照：
| 部分 | 内容 | 含义 |
|---|---|---|
| 类型 | feat |
这是一个新功能 |
| 范围 | (login) |
影响的是登录模块 |
| 分隔 | : |
冒号加空格 |
| 描述 | 新增手机号验证码登录功能 |
具体做了什么 |
是不是一下就看懂了？谁看到这条提交，都能秒懂"哦，这次在登录模块加了个验证码登录"。
四、核心！最常用的提交类型 + 场景示例
这一部分是本文的重点。我会按照"遇到什么场景 → 该用什么前缀"的思路来讲，你可以直接对号入座。
4.1 最常用的两个类型：feat 和 fix
feat —— 新增功能
使用场景：你写了一段全新的、项目里之前没有的功能代码。
示例1：给网站加了一个"用户登录"功能
feat: 新增用户登录功能
示例2：给购物车加了一个"一键清空"按钮
feat(cart): 新增一键清空购物车功能
fix —— 修复bug
使用场景：你解决了一个已经存在的问题或错误。
示例1：购物车的结算按钮点了没反应，你把它修好了
fix(cart): 修复购物车无法结算的问题
示例2：登录页面在手机上显示错位，你调好了
fix(login): 修复移动端登录页面错位问题
💡 小贴士：
feat和fix是99%场景下你会用到的两个类型。哪怕你只记住这两个，也足以应付大部分日常开发了。剩下的类型可以慢慢熟悉。
4.2 容易混淆的几个类型（重点辨析）
下面几个类型经常让新手拿不准，我们逐个辨析清楚。
docs —— 只改文档
使用场景：你只改了 README、注释、说明文档，没有碰任何实际的代码逻辑。
示例：给项目补充了安装说明
docs: 补充项目安装步骤说明
辨析提醒：如果你在代码里加了几行注释来解释某段逻辑，这也算 docs，因为你没有改变代码的实际行为。
style —— 纯格式调整
使用场景：你只调整了代码的缩进、空格、分号、格式化等，代码的运行逻辑完全没有改变，纯粹是让它"更好看"。
示例：用 Prettier 把整个文件格式化了一遍
style: 统一代码缩进格式
辨析提醒：style 的关键在于不影响代码运行。它和下面要讲的 refactor 的区别是：style 完全不动逻辑结构，只动排版。
refactor —— 代码重构
使用场景：你修改了代码的结构、写法、变量名、函数名等，但功能表现和之前完全一样——既没有修bug，也没有加新功能。
示例：把散落在三处的重复代码提取成一个公共函数
refactor: 提取重复的表单验证逻辑为公共函数
辨析提醒：判断标准很简单——如果这次改动"用户完全感知不到任何变化"，而且不只是排版格式的调整，那它就是 refactor。
test —— 测试相关
使用场景：你新增或修改了测试用例。
示例：给登录接口补充了单元测试
test: 新增登录接口单元测试
chore —— 杂项/工程化事务
使用场景：不属于以上任何类型的"打杂"工作，比如升级依赖、修改一些无关业务的配置。
示例：升级了项目里的 lodash 版本
chore: 升级lodash到最新版本
4.3 进阶类型（了解即可，按需使用）
下面这几个类型用得相对少一些，你先混个眼熟，遇到对应场景再回来查即可。
| 类型 | 使用场景 | 示例 |
|---|---|---|
build |
修改构建工具配置 | build: 更新webpack打包配置 |
ci |
修改CI/CD流程配置 | ci: 修改GitHub Actions工作流 |
perf |
性能优化相关改动 | perf: 优化首页图片加载速度 |
4.4 速查：我该用哪个前缀？
如果还是拿不准，照着下面这个决策清单从上往下一条条问自己，第一个符合的就是答案：
这次改动是否新增了功能？ → 是 → feat
是否修复了一个 bug？ → 是 → fix
是否只改了文档/注释？ → 是 → docs
是否只是格式调整（不改逻辑）？ → 是 → style
是否重构了代码（逻辑不变）？ → 是 → refactor
是否是测试代码相关？ → 是 → test
是否是依赖/配置等杂项？ → 是 → chore
把这张表存下来，写提交信息的时候扫一眼，基本不会用错。
五、进阶知识：破坏性变更怎么标记？（选学内容）
这一节是给有余力的读者的拓展内容，刚入门可以先跳过。
5.1 什么是"破坏性变更"
简单说，破坏性变更指的是这次改动会导致老版本的用法失效、不再兼容。别人依赖你旧代码写的东西，升级后可能直接报错。这种改动影响很大，必须显眼地标出来。
5.2 两种标记方式
方式一：在提交信息的脚注部分写 BREAKING CHANGE:，后面跟上对变更的描述。
feat: 修改用户接口返回格式
BREAKING CHANGE: 返回字段 userName 改为 username，调用方需同步修改
方式二：在类型（或范围）后、冒号前加一个感叹号 !。
feat(api)!: 修改用户接口返回格式
示例场景：假设你把接口返回的字段名从 userName 改成了 username。所有还在用 userName 的老代码调用后都会拿不到数据、报错。这种情况下，就应该把它标记为破坏性变更，提醒所有人注意升级。
六、让规范自动生效：推荐工具
看到这里你可能会想：这套规范虽然好，但全靠大家自觉遵守，万一有人偷懒随便写怎么办？
好消息是，有工具可以帮你"强制执行"。介绍两个常用的组合：
- commitlint：一个自动检查提交信息的工具。它会按照约定式提交的规则，检查你写的提交信息格式对不对、类型词合不合法。
- husky：一个能在 Git 操作时触发脚本的工具。把它和 commitlint 组合起来，就能实现：每当你执行
git commit时，自动跑一遍检查，如果提交信息不符合规范，直接拦截提交，让你重写。
这两个工具搭配使用，能让团队里所有人都"被迫"遵守规范，再也不用靠个人自觉了。对于多人协作的项目来说，这几乎是保证提交质量的必备配置。
七、总结：从今天开始，写"有意义"的提交
我们回顾一下这篇文章的重点：
- 先记住两个最常用的：
feat（新功能）和fix（修bug），它们覆盖了绝大多数日常开发场景。剩下的docs、style、refactor、test、chore等可以慢慢熟悉。 - 格式很简单：
<类型>(可选范围): <描述>，一句话就能写好。 - 拿不准时看决策清单：从"是不是新功能"开始一条条问下去。
规范提交绝不是"形式主义"。它是一件让未来的你和整个团队都会感谢的事——当有一天你需要回溯问题、生成日志、追踪某个改动时，清晰的提交历史会为你省下大量时间。
行动号召：下次提交代码时，试着用一次约定式提交。哪怕只是把"改了点东西"换成 fix: 修复登录按钮无响应问题，你也会立刻感受到那份清爽。
如果想深入学习完整的规范细节，可以去 conventionalcommits.org 官网了解更多。从今天起，让你的每一次提交都有意义吧！
