小王刚入职新公司，第一次 push 代码就被组长叫去喝茶——因为他的 commit 记录是这样的：
git commit -m "fix"再翻下一条：
git commit -m "ok"还有更绝的：
git commit -m "123"不是他懒，是他真不知道怎么写才算合格。其实 Git 提交不是记流水账，而是给团队（包括未来的自己）留一份可读、可追溯、能快速定位问题的日志。
为什么规范提交很重要？
你删掉的那行代码，可能三个月后被 QA 找出来是线上 bug 的根源；别人看到 git commit -m "update"，根本没法判断改的是配置、接口还是样式。而一条清晰的提交信息，能让同事不用切分支、不用翻 diff 就知道：改了什么、为什么改、是否影响其他模块。
推荐用「约定式提交」（Conventional Commits）
这是目前最接地气、上手快、工具链支持好的规范。格式很简单：
<type>[optional scope]: <description>比如：
feat(user): 添加邮箱登录校验逻辑fix(api): 修复用户列表分页参数丢失问题docs(readme): 更新部署步骤说明常用 type 有：feat（新功能）、fix（修 bug）、docs（文档）、style（格式调整，不改逻辑）、refactor（重构）、test（测试）、chore（构建/脚本等杂务）。
别忽略描述后的细节
如果改动涉及关键逻辑或需特别注意，可以空一行加 body：
refactor(payment): 统一订单状态处理流程
- 将 statusCheck 从组件内抽离为 utils 函数
- 避免在多个页面重复实现相同判断逻辑
- 后续接入新支付渠道时可复用这样比光看标题更清楚“动了哪根筋”。
顺手养成几个小习惯
• 提交前先 git status 看一眼，避免误提无关文件；
• 大功能拆成多个原子提交，比如「加字段 → 改接口 → 更新 UI」不要挤在一个 commit 里；
• 本地频繁修改时，别怕用 git commit --amend 合并或修正上一条；
• 如果用 VS Code，装个「Commitizen」插件，点选 type 和 scope，描述自动补全，省得手敲还拼错。
规范不是为了应付检查，而是让协作像拧螺丝一样顺——谁拧的、拧在哪、为啥要拧紧，一目了然。