name: commit-message description: 根据差异和上下文建议常规提交消息。在提交更改、编写提交消息或总结暂存更改时使用。
提交消息
根据git差异、暂存更改和上下文，建议清晰、常规的提交消息。
使用时机
- 用户即将提交并询问消息时
- 用户想要总结暂存或未暂存的更改时
- 用户询问“我应该使用什么提交消息？”时
工作流程
- 检查更改：
git diff --staged（如果无暂存则用git diff） - 识别类型：feat、fix、docs、style、refactor、test、chore
- 识别范围：可选，如auth、api、ui
- 总结：简短、命令式描述
- 可选正文：如果不明显，说明原因和内容
- 可选页脚：Fixes #N、Breaking change
常规提交格式
<type>(<scope>): <short description>
[optional body]
[optional footer]
类型
| 类型 | 使用时机 |
|---|---|
| feat | 新功能或能力 |
| fix | 错误修复 |
| docs | 仅文档更改 |
| style | 格式化、空格，无逻辑更改 |
| refactor | 非修复或功能的代码更改 |
| test | 添加或更新测试 |
| chore | 构建、工具、依赖、配置 |
| perf | 性能改进 |
范围（可选）
- 包、模块或区域：
auth、api、ui、cli - 从更改路径推断：
src/auth/→ 范围auth
简短描述
- 命令式、小写、无句号：例如“添加登录”而非“添加了登录”
- 主题行约50字符以内
- 描述更改内容，而非原因（原因可在正文中说明）
示例
从添加OAuth登录的差异：
feat(auth): 添加OAuth2登录
从修复用户查找中null的差异：
fix(api): 处理用户查找中的null
从仅涉及README的差异：
docs: 更新README安装步骤
从重构存储但不更改行为的差异：
refactor(store): 提取用户选择器
从升级依赖的差异：
chore(deps): 升级react至18.2
正文（可选）
使用时机：
- 原因不明显时
- 有重大更改时
- 非平凡理由时
feat(api): 添加列表端点的分页
重大更改：列表端点现在返回 { items, nextCursor } 而非普通数组。
页脚（可选）
Fixes #123或Closes #123用于问题Breaking change: ...用于重大更改
收集上下文
# 暂存更改（首选）
git diff --staged --stat
git diff --staged
# 无暂存时的未暂存更改
git diff --stat
git diff
# 最近提交以了解风格
git log -3 --oneline
从以下推断类型和范围：
- 文件路径（如
src/auth/、docs/） - 内容（新函数vs重命名vs删除）
- 测试文件 → 类型
test或在正文中提及
多个逻辑更改
如果暂存更改混合多个关注点：
- 建议拆分：“考虑分两次提交：1) feat(auth): … 2) docs: …”
- 或建议一个覆盖主要主题的消息，并在正文中注明"包括X和Y"
语气
- 中立和事实性
- 命令式语气（“添加"而非"添加了”）
- 消息中无表情符号或夸张，除非项目约定使用
反模式
- ❌ “修复东西”、“更新”、“WIP”
- ❌ 过去时（“修复了bug”）
- ❌ 主题行末尾句号
- ❌ 非常长的主题行（改为在正文中换行）