Smart Commit
Generate precise, conventional commit messages from staged git changes and optionally commit in one step.
Workflow
- 1. Run
git diff --cached --stat to see what's staged. If nothing is staged, check git diff --stat and ask the user if they want to stage all changes first. - Run
git diff --cached to get the full diff (if very large, use --stat summary + sample key hunks). - Analyze the diff and generate a commit message following the rules below.
- Present the message to the user. If approved, run
git commit -m "<message>".
Commit Message Format
Follow Conventional Commits:
CODEBLOCK0
Rules
- - type: One of
feat, fix, refactor, docs, chore, test, style, perf, ci, INLINECODE14 - scope: Optional. Infer from changed files (e.g.,
auth, api, ui, db). Omit if changes span too many areas. - subject: Imperative mood, lowercase, no period, max 72 chars. Be specific — not "update files" but "add retry logic to HTTP client".
- body: Add only when the "why" isn't obvious from the subject. Wrap at 72 chars.
- breaking changes: Add
! after type/scope and BREAKING CHANGE: footer. - Multiple logical changes: If the diff contains clearly unrelated changes, suggest splitting into multiple commits with
git add -p.
Type Selection Guide
| Signal | Type |
|---|
| New feature, new endpoint, new UI element | INLINECODE22 |
| Bug fix, error correction, patch |
fix |
| Code restructure, no behavior change |
refactor |
| Comments, README, docs, JSDoc |
docs |
| Dependencies, configs, tooling |
chore |
| Test files added/modified |
test |
| Formatting, whitespace, linting |
style |
| Performance improvement |
perf |
| CI/CD pipeline changes |
ci |
| Build system, compilation |
build |
Quality Checklist
Before presenting the message, verify:
- - [ ] Subject is specific and descriptive (someone reading
git log --oneline can understand the change) - [ ] Type accurately reflects the change
- [ ] Scope is correct or intentionally omitted
- [ ] No vague words: "update", "change", "modify", "fix stuff", "misc"
- [ ] Breaking changes are flagged if applicable
Examples
Single file fix:
CODEBLOCK1
Multi-file feature:
CODEBLOCK2
Breaking change:
CODEBLOCK3
Chore:
CODEBLOCK4
Large Diffs
For diffs exceeding ~4000 lines:
- 1. Use
git diff --cached --stat for overview - Read key files with INLINECODE34
- Summarize the overall change from the stat + sampled hunks
- If changes are too diverse, recommend splitting the commit
Options
The user may specify preferences:
- -
--no-body: Skip the body, subject only --scope <name>: Force a specific scope--type <type>: Force a specific type--amend: Amend the previous commit instead--dry-run: Generate message without committing
智能提交
根据暂存的Git变更生成精确的常规提交信息，并可选择一步完成提交。
工作流程
- 1. 运行 git diff --cached --stat 查看已暂存的内容。如果未暂存任何内容，则检查 git diff --stat 并询问用户是否希望先暂存所有更改。
- 运行 git diff --cached 获取完整差异（如果非常大，则使用 --stat 摘要和关键代码块样本）。
- 分析差异并根据以下规则生成提交信息。
- 向用户展示信息。如果获得批准，则运行 git commit -m 。
提交信息格式
遵循常规提交规范：
<类型>(<范围>): <主题>
[可选正文]
[可选页脚]
规则
- - 类型：feat、fix、refactor、docs、chore、test、style、perf、ci、build 之一
- 范围：可选。根据更改的文件推断（例如 auth、api、ui、db）。如果更改涉及过多领域则省略。
- 主题：祈使语气、小写、无句号、最多72个字符。要具体——不是更新文件而是为HTTP客户端添加重试逻辑。
- 正文：仅当主题无法明确说明为什么时添加。每行72个字符换行。
- 破坏性变更：在类型/范围后添加 ! 并添加 BREAKING CHANGE: 页脚。
- 多个逻辑变更：如果差异包含明显不相关的更改，建议使用 git add -p 拆分为多个提交。
类型选择指南
| 信号 | 类型 |
|---|
| 新功能、新端点、新UI元素 | feat |
| 错误修复、纠错、补丁 |
fix |
| 代码重构，无行为变化 | refactor |
| 注释、README、文档、JSDoc | docs |
| 依赖项、配置、工具 | chore |
| 添加/修改测试文件 | test |
| 格式化、空白、代码风格 | style |
| 性能改进 | perf |
| CI/CD流水线变更 | ci |
| 构建系统、编译 | build |
质量检查清单
在展示信息之前，请验证：
- - [ ] 主题具体且具有描述性（阅读 git log --oneline 的人能理解变更内容）
- [ ] 类型准确反映变更
- [ ] 范围正确或有意省略
- [ ] 无模糊词汇：更新、更改、修改、修复问题、杂项
- [ ] 破坏性变更已标记（如适用）
示例
单文件修复：
fix(auth): 处理刷新流程中过期的JWT令牌
多文件功能：
feat(api): 为列表端点添加分页支持
为 /users、/posts 和 /comments 实现基于游标的分页。
默认页面大小为20，最大100。
破坏性变更：
feat(config)!: 从YAML迁移到TOML配置
BREAKING CHANGE: 不再支持 config.yaml。
运行 migrate-config 转换现有配置。
杂项：
chore(deps): 将 express 从 4.18.2 升级到 4.19.0
大型差异
对于超过约4000行的差异：
- 1. 使用 git diff --cached --stat 获取概览
- 使用 git diff --cached -- <重要文件> 读取关键文件
- 从统计信息和采样代码块中总结整体变更
- 如果变更过于分散，建议拆分提交
选项
用户可以指定偏好：
- - --no-body：跳过正文，仅主题
- --scope <名称>：强制指定范围
- --type <类型>：强制指定类型
- --amend：改为修改上一次提交
- --dry-run：仅生成信息而不提交
