写 Git 提交信息别再瞎写了
以前我写 commit message 就三种风格：
update（更新了啥？鬼知道）fix bug（哪个 bug？不说）111111（纯纯摆烂）
后来回滚代码的时候，对着 git log 一脸懵逼——这堆提交里到底哪个是改样式的、哪个是修接口的、哪个是重构的？根本分不清。
直到我学习了 约定式提交（Conventional Commits）这种规范，才发现原来 commit message 可以写得既规范又省事。
一句话说清楚
约定式提交就是给你的 commit 套一个固定格式：
plain
<类型>[可选范围]: <描述>
[可选正文]
[可选脚注]翻译成人话：先告诉别人你这次干了什么性质的事，再说具体干了啥。
常用类型速查表
别记太多，这几个够你日常用了：
表格
| 类型 | 什么时候用 | 举个栗子 |
|---|---|---|
feat | 加了新功能 | feat: 新增用户登录接口 |
fix | 修了 bug | fix: 修复空指针导致崩溃 |
docs | 只改文档 | docs: 更新 README 部署说明 |
style | 代码格式调整 | style: 统一缩进为4空格 |
refactor | 重构，不改功能 | refactor: 提取公共请求方法 |
perf | 性能优化 | perf: 减少数据库查询次数 |
test | 改测试相关 | test: 补充单元测试覆盖 |
chore | 杂活（改配置、构建等） | chore: 升级依赖版本 |
看到没，
chore就是万能垃圾桶，不知道归哪类就扔给它。
带范围的写法（进阶但好用）
如果你项目比较大，可以加上 范围 告诉别人你动的是哪个模块：
plain
feat(auth): 添加 JWT token 刷新机制
fix(api): 修复分页参数越界
docs(readme): 补充本地启动步骤这样一眼就能看出：哦，这是认证模块的事，跟我负责的订单模块没关系，review 的时候省心多了。
破坏性变更怎么写？
如果你这次改动会让老代码挂掉（比如删了旧接口、改了传参格式），必须标出来：
方式一：加感叹号
plain
feat(api)!: 移除 v1 版本接口，强制使用 v2方式二：脚注里写 BREAKING CHANGE
plain
feat: 调整用户数据结构
BREAKING CHANGE: `phone` 字段改为 `phoneNumber`，旧字段已废弃这样别人升级的时候就不会一脸问号地报错了。
这玩意儿到底有啥用？
说实话，刚开始我也觉得麻烦——写个提交信息还要遵守规范？但用久了发现真香：
- 自动生成 CHANGELOG：不用手动整理版本更新了啥，工具直接帮你从 commit 里提取
feat和fix生成日志。 - 语义化版本自动推：
fix对应补丁版本（1.0.1），feat对应小版本（1.1.0），破坏性变更对应大版本（2.0.0），CI 能自动帮你打 tag。 - 代码审查效率高：扫一眼
git log就知道这次提交是改 bug 还是加功能，不用点开文件一个个看。 - 历史记录能看了：三个月后再回来看，至少知道每个提交大概在干嘛。
几个我常用的模板
简单修复：
plain
fix: 修复内存泄漏导致服务重启带正文说明：
plain
feat: 支持批量导入用户
之前只能单个添加，运营同事反馈效率太低。
现在支持 Excel 批量导入，单批次上限 1000 条。
Closes: #42改配置：
plain
chore: 修改测试环境数据库地址
BREAKING CHANGE: 本地开发需要重新配置 .env 文件最后说两句
约定式提交不是让你写八股文。它其实就一条核心原则：让别人（包括三个月后的你自己）一眼看出这个提交是干嘛的。
刚开始可能不习惯，但坚持一两个星期，你会发现 git log 终于不再是灾难现场了。
而且，面试的时候你说”我们项目使用约定式提交规范”，也是能加分的小细节——至少证明你关注代码质量和团队协作。
P.S. 如果你还在写 update 和 fix bug，建议从今天开始试试 feat: 和 fix:，真的不麻烦。