用途：为 Git 提交编写规范、可读的提交信息，便于人类阅读和自动化工具解析。
格式：<type>(<optional scope>): <subject>，后接可选正文与可选页脚。
主题行规则：不超过 50 字符；使用祈使语气（如 add feature，而非 added/adding）；类型前缀后首字母不大写；结尾不加句号。
类型：feat（面向用户的新功能）、fix（缺陷修复）、refactor（不改变行为的重构）、docs（文档）、test（测试）、chore（构建、CI、工具、依赖）、perf（性能）、style（格式与空白，非 CSS）、ci（CI/CD 流水线）、revert（回滚提交）。
作用域（可选）：标明受影响的代码区域，如 feat(auth): add OAuth2 login flow、fix(api): handle null response from payments endpoint、refactor(db): extract query builder into module。
正文（需要时）：解释为什么，而非做了什么（diff 已展示改动内容）。
页脚（需要时）：可写 BREAKING CHANGE:、Closes #456、Co-authored-by: Name <email>。
示例：feat(dashboard): add real-time notification bell；fix: resolve race condition in WebSocket reconnect；refactor(api): consolidate error handling middleware；test: add integration tests for payment webhook；chore: upgrade TypeScript to 5.4。应避免 fixed stuff、WIP、update、changes、asdf 等无意义信息。
提交时机：每次提交代表一个逻辑变更；不要在同一提交中混合重构与功能；不要提交半成品代码（可用 git stash）；在功能分支上尽早、频繁提交，必要时合并前压缩。
破坏性变更：在类型后加 !，如 feat(api)!: change auth token format；并在页脚写 BREAKING CHANGE: 及迁移说明。
限制：资料未提供安装命令、平台支持、收费或价格信息。