feat和fix分别表示新增功能与修复bug，须按“type(scope): 动词开头的简短描述”格式书写，scope应具体明确，subject需精准说明行为变更且不超过50字符。
直接写 feat 或 fix 开头，后面跟括号注明模块、冒号、空格、动词开头的简短描述——这是最稳妥的起点，90% 的日常提交按这个格式就能被工具识别、被同事快速理解。
feat 和 fix 到底怎么选
选 feat 还是 fix，不看改动“多不多”，而看是否引入了新能力或修正了异常行为：
-
feat：用户能感知的新功能，比如登录页加了微信扫码入口、API 新增了分页参数 -
fix：修复了本不该出现的问题，比如点击按钮没反应、金额计算为负数、接口返回 500 - 别用
fix描述“改得更顺手”或“看着不舒服”的调整；这类属于refactor或style - 如果改了一堆文件但本质就一件事（比如统一替换某个过时 SDK），仍用一个
feat或fix，别拆成多个提交
scope 括号里填什么才不白写
scope 不是装饰，它决定你以后能不能用 git log --grep="user" 快速筛出所有用户模块变更。填错等于没填：
- 优先填具体模块名：
feat(auth)、fix(payment)、docs(api) - 避免泛化词：
feat(frontend)、fix(server)—— 太宽，失去定位价值 - 如果影响跨模块（比如改了公共工具函数），填
utils或shared，别写all或留空 - 不确定 scope 时，先看项目已有提交里同类改动怎么写的，保持一致比“绝对正确”更重要
subject 描述为什么总被写成废话
“修复 bug”“新增功能”“优化代码”——这类描述等于没写。真正有用的 subject 要让读者一眼知道“改了什么行为”：
- ✅
fix(cart): prevent duplicate item addition on rapid click - ✅
feat(search): support fuzzy matching for product names - ❌
fix: bug fix（信息密度为 0） - ❌
feat: new search feature（没说新在哪） - 动词必须是祈使式（add / support / prevent / remove），不是过去式（added / supported）
- 长度控制在 50 字符内，超了说明没提炼核心
最容易被忽略的是：一个提交只做一件事，且这件事必须能被 type + scope + subject 三者共同锁定。AI 助手或新手常把样式调整、逻辑修复、依赖升级塞进同一个 commit，结果 git revert 时进退两难——这不是规范问题，是工作流设计缺陷。
