在工程世界，Commit Message 就像项目的"航行日志"。写得清楚，回溯历史像看说明书；写得随意，排查问题像考古现场。
业界最常用方案叫 Conventional Commits。目标只有一个：让提交记录可读、可追踪、可自动化处理。
一、Commit Message 基本语法规则
一个规范的 Commit Message，本质是一条可读、可检索、可自动处理的结构化信息，而不是随手备注。
标准结构
<type>(<scope>): <subject>这一行信息，决定提交记录是否具备工程价值。
1️⃣ type（提交类型）
定义
用于描述本次提交的核心目的，是 Commit Message 中权重最高的字段。
作用
- 快速判断提交性质
- 支持自动生成 CHANGELOG
- 提升代码审查效率
示例说明
feat 表示引入新能力。
fix 表示修正异常行为。
2️⃣ scope（影响范围，可选）
定义
用于标明本次提交影响的模块或业务范围。
常见取值
- 模块名
- 功能名
- 目录名
工程价值
scope 存在时，历史记录可以按模块精准定位。
scope 缺失时，提交语义容易泛化。
3️⃣ subject（提交简述）
定义
使用一句话概括本次提交行为。
书写要求
- 动词开头
- 描述行为本身
- 信息密度高于情绪表达
示例思路
不是"改点东西"，而是"支持手机号登录"。
不是"修下 Bug"，而是"修复订单金额计算异常"。
✅ 推荐示例
feat(user): 支持手机号登录语义拆解
- feat 表示新功能引入
- user 指向用户模块
- subject 直接说明能力变化
阅读成本接近零，历史价值极高。
❌ 不推荐示例
修改代码
更新一下
test问题分析
- 无法判断提交目的
- 无法定位影响范围
- 无法服务未来维护
这类提交记录存在感强，工程价值接近注释里的 TODO。
二、所有标准 Commit 类型大全
这一节相当于 Commit Message 的字典页。
当你不知道 type 怎么选，翻到这里，问题基本结束。
1️⃣ feat 新功能
含义
用于引入用户可感知的新能力、新接口或新流程。
使用场景
- 新页面接入
- 新接口提供
- 新业务流程上线
示例
feat(auth): 新增短信验证码登录判断口诀
👉 用户打开产品后能察觉变化，优先选择 feat。
2️⃣ fix 修复问题
含义
用于修正异常行为、错误逻辑或非预期结果。
使用场景
- 崩溃问题处理
- 逻辑分支修正
- 显示异常修正
示例
fix(order): 修复订单金额计算错误判断口诀
👉 预期行为未达成，通过提交恢复正常状态，选择 fix。
3️⃣ docs 文档变更
含义
仅涉及文档内容，不触及业务逻辑与功能行为。
使用场景
- README 补充
- 接口说明调整
- 注释内容完善
示例
docs(readme): 补充本地启动说明工程冷知识
文档越清晰，后来者越少对着代码发呆。
4️⃣ style 代码风格调整
含义
仅调整代码外观，不改变任何执行结果。
使用场景
- 缩进对齐
- 分号补齐
- 换行整理
示例
style: 格式化 eslint 规则注意事项
禁止夹带逻辑修改，否则提交记录失去参考价值。
5️⃣ refactor 重构
含义
在不改变功能行为前提下，对代码结构进行优化。
使用场景
- 抽取公共函数
- 拆分模块职责
- 提升代码可读性
示例
refactor(api): 拆分请求封装逻辑判断口诀
👉 外部表现一致，内部结构更顺眼。
6️⃣ perf 性能优化
含义
以性能提升为唯一目标的代码调整。
使用场景
- 减少重复计算
- 降低内存占用
- 提升响应速度
示例
perf(list): 优化长列表渲染性能小提示
性能相关修改单独提交，方便对比与回溯。
7️⃣ test 测试相关
含义
新增或调整测试代码，不影响生产逻辑。
使用场景
- 单元测试补充
- 集成测试完善
示例
test(user): 新增登录流程测试工程共识
测试存在感低，工程价值极高。
8️⃣ build 构建相关
含义
影响构建流程、依赖管理或打包行为。
使用场景
- Webpack 配置调整
- Vite 升级
- 打包参数修改
示例
build: 升级 vite 到最新版本9️⃣ ci 持续集成
含义
用于持续集成与自动化流程配置调整。
使用场景
- GitHub Actions
- GitLab CI
- 自动化测试流程
示例
ci: 添加自动化测试流程🔟 chore 杂项事务
含义
不直接影响功能，但必须纳入版本控制的事务。
使用场景
- 依赖版本更新
- 脚本整理
- 配置文件清理
示例
chore: 更新依赖版本温馨提醒
chore 使用频率高，滥用会模糊提交意图。
1️⃣1️⃣ revert 回滚提交
含义
用于撤销某一次已有提交。
示例
revert: 回滚 feat(auth): 新增短信验证码登录推荐做法
使用 git revert 生成提交信息，语义更准确。
三、操作步骤
规范的 Commit Message，不靠灵感发挥，而靠固定流程执行。
按照下面三步操作，提交记录稳定保持工程级水准。
步骤一：查看修改内容
git status📘 说明
该命令用于查看当前工作区与暂存区状态，明确哪些文件发生变化、哪些内容尚未纳入版本控制。
在提交之前执行一次 git status，可以有效避免把调试文件、临时日志或无关改动一起提交。
良好的提交，从确认修改范围开始。
步骤二：添加到暂存区
git add .📘 说明
. 表示当前目录下的全部改动内容，包括新增、修改与删除。
当修改内容较多或涉及多个模块时，建议配合 git add <file> 精确控制提交范围。
提交粒度越清晰，后续回溯成本越低。
步骤三：编写规范提交信息
git commit -m "feat(user): 支持头像上传"📘 说明
- feat 表示本次提交引入新能力
- user 指向用户相关模块
- subject 使用动词短句描述行为本身
该写法可以让任何成员在阅读提交记录时，直接理解本次修改目的，而不需要翻代码确认。
当每一次提交都遵循统一语法，Git 日志自然具备文档属性。
四、团队实践建议
1️⃣ 一个提交只做一件事
每次提交聚焦单一功能或修复。
如果提交内容杂乱无章，回滚或审查时就像拼图找碎片。
保持提交单一目标，让未来接手的同事少翻代码。
2️⃣ 提交信息可读性优先
Commit Message 是团队共享语言。
清晰简洁的语句比长篇注释更高效。
动词开头、主题明确，让每个人看一次就明白你做了什么。
3️⃣ 自动生成 CHANGELOG 更省心
当团队坚持规范 type、scope 和 subject，使用工具生成 CHANGELOG 就像开挂一样简单。
版本日志自动整理，发布说明不再靠脑补。
4️⃣ 配合 Commit Lint 强制规范
使用 Commit Lint 或 Husky，可以在提交前拦截不规范信息。
即便是最马虎的程序员，也会被规范"教育"成好公民。
五、总结
好 Commit 不是形式主义，而是团队效率加速器。
干净、语义明确、结构统一的提交记录，会带来三大好处：
- 回滚更轻松：查找问题像翻书，不用盲目猜测
- 评审更高效：同事无需费神理解你的意图
- 接盘更安心：新人接手项目，像阅读技术文档而不是看历史聊天记录
当团队每个人都坚持规范，Git 历史就不再是流水账，而是一份可追溯、可检索、可复用的项目演进文档。
提交规范其实就是给未来自己发的一封感谢信，写好它，团队效率自然加倍。