用途：强制项目内每次 git commit 的提交信息都符合 Conventional Commits 1.0.0 规范，不符合规范的信息必须拒绝并重写。也可在用户要求“写 conventional commit”或“格式化提交信息”时使用。
结构：<type>[optional scope]: <description>，之后可选空行加正文，再可选空行加页脚。type 必填，scope 为括号内名词用于缩小范围，! 紧跟冒号前标记破坏性变更，description 必填且使用祈使语气、72 字符内、首字母不大写、结尾不加句号。
类型与 SemVer：feat 对应 MINOR，fix 对应 PATCH，docs、style、refactor、perf、test、build、ci、chore、revert 默认不自动升版；只有 feat 和 fix 有隐式 SemVer 含义，其他类型仅在带破坏性变更标记时才升 MAJOR。
破坏性变更：两种等价写法，可在 type/scope 后加 !，或使用页脚 BREAKING CHANGE: 说明；页脚必须使用大写 BREAKING CHANGE，BREAKING-CHANGE 为合法同义词，可同时使用两种方式。
步骤：先判断改动主要意图，再从类型表选择唯一最合适类型，若跨多种类型应拆分为多个提交；随后可选定作用域，判断是否需使用者修改代码以决定破坏性变更，接着写祈使语气描述，必要时加解释原因的正文（72 字符换行），最后用 Token: value 格式加页脚。
页脚：支持 BREAKING CHANGE、Refs、Reviewed-by、Co-authored-by、Fixes 等，令牌名用连字符代替空格，BREAKING CHANGE 是唯一可含空格的例外。作用域建议按模块、层次或 UI 区域命名，并在项目内保持一致。
常见错误：描述含糊、类型选错、一次提交混合多个意图、正文或页脚前缺少空行、破坏性变更用小写、冒号后缺空格。规范可被 semantic-release、standard-version、commitlint 等工具解析以自动升版。参考资料包括 references/commit-types.md 与 references/advanced-patterns.md。