git commit message 规范写法（Conventional Commits）
好的提交信息让历史清晰、方便回溯与自动生成 changelog。本文讲清 Conventional Commits 规范：feat/fix/docs 等类型、作用域、正文写法，并给真实示例。
场景：每次 git commit -m 都想写清楚"这次干了啥"，但团队或你自己回看历史时，发现全是"更新""修改""bugfix"这类没信息量的信息。用 Conventional Commits 规范能彻底改善。
规范核心：类型 + 描述
一行提交信息的推荐格式：
<type>(<scope>): <subject>git commit -m "feat: 添加用户登录功能"
git commit -m "fix(cart): 修复购物车数量为负的问题"- type：改动类型（必填）
- scope：作用域（可选，如模块名 cart）
- subject：简短描述（用祈使句，说明"做了什么"）
常用类型表
| type | 含义 |
|---|---|
feat | 新功能 |
fix | 修复 bug |
docs | 文档改动 |
style | 格式(不影响逻辑，如空格) |
refactor | 重构(不改功能不改 bug) |
test | 测试相关 |
chore | 杂项(构建/依赖等) |
perf | 性能优化 |
ci | CI 配置改动 |
破坏性变更
feat!: 更改 API 不再向后兼容或带正文说明：
BREAKING CHANGE: 移除旧的 xx 接口完整规范（含正文）
复杂提交可分三部分：
git commit -m "feat(user): 添加找回密码功能
用户可通过邮箱验证重置密码
- 新增发送验证码接口
- 新增重置密码页面
BREAKING CHANGE: 旧的 /reset 接口已废弃"第一行是主题，空一行后是正文，可列细节。
为什么用这套规范
- 历史可读：
git log --oneline一眼看出每个提交类型 - 自动生成 changelog：semantic-release 等工具按 feat/fix 自动归类
- 触发版本号：feat 升次版本、fix 升修订号、BREAKING 升主版本
- 团队协作清晰：review 时能快速判断改动意图
常见错误示例
| ❌ 差 | ✅ 好 |
|---|---|
| update code | fix: 修复空指针异常 |
| 修改 | feat: 新增订单导出功能 |
| bugfix | fix(api): 修复接口超时 |
| 一堆改动 | 拆成多个语义提交 |
推荐习惯
- 主题行 ≤ 50 字符，简洁
- 一个提交只做一件事（原子提交）
- 描述用祈使句："Add" 而非 "Added"
一句话速记
type(scope): 描述，feat 新功能、fix 修 bug、docs 文档…统一前缀让历史清晰可自动生成 changelog。
?
常见问题 FAQ
feat 和 fix 开头是什么意思?
这是 Conventional Commits 规范中的"类型(type)"。feat 表示新功能，fix 表示修复 bug。用统一类型前缀让提交历史一眼可读。
提交信息带感叹号如 feat! 是什么意思?
感叹号表示"破坏性变更"(breaking change)，例如 API 不兼容。它常配合 BREAKING CHANGE 或 ! 提示会带来不向下兼容的改动，通常触发主版本号升级。
中文项目能用中文提交信息吗?
可以。类型前缀建议保留英文(feat/fix 等)，描述部分用中文更直观，如 feat: 添加登录功能。关键是团队统一。
写错提交信息后怎么改?
若尚未 push，用 git commit --amend -m "新信息" 修改最近一次；若已推送需慎重(改写历史)。规范提交可配合 --amend 修正。