Git Commit

📝 Git Commit 规范生成器

根据代码变更，生成规范的 commit message，告别 "fix bug" 和 "update"

支持的 Commit 类型

工作流程

Step 1：获取变更内容

使用以下方式之一：

# 查看暂存区变更
git diff --cached

# 查看工作区变更
git diff

# 查看最近提交
git log -3 --oneline

Step 2：分析变更类型

识别本次变更的核心内容：

• 改了哪些文件？
• 核心改动是什么（新增/修复/重构）？
• 涉及哪个模块？

Step 3：生成 Commit Message

输出格式

格式一：Conventional Commits（推荐团队使用）

<type>(<scope>): <subject>

[optional body]

[optional footer]

示例：

feat(crm): 新增客户跟进记录查询接口

支持按跟进时间/跟进人筛选，返回完整的跟进记录列表。
关联工单：PROJ-123

格式二：简洁单行（日常小改动）

<type>: <简短描述>

示例：

fix(mmp): 修复订单状态枚举值错误

fix(user): 修正用户头像URL为空时报错
docs(readme): 更新部署文档

常见场景模板

🐛 修复生产问题

fix(<模块>): 修复<问题描述>

问题原因：<根因>
修复方案：<解决方式>
影响范围：<涉及的接口/页面>

✨ 新增功能

feat(<模块>): 新增<功能名称>

功能说明：
- <子功能点1>
- <子功能点2>

关联需求：<需求编号>

🔄 代码重构

refactor(<模块>): 重构<原有逻辑>为<新实现>

改动原因：<为什么要改>
改动范围：<涉及的文件>
注意事项：<兼容性问题等>

📝 文档更新

docs(<模块>): 更新<文档名称>

更新内容：
- <更新点1>
- <更新点2>

分支命名规范

配合 Commit Type，建议分支命名：

feature/模块-功能名        # 新功能
bugfix/模块-问题简述        # 修复bug
hotfix/问题简述             # 紧急修复
refactor/模块-重构内容       # 重构
docs/文档内容               # 文档

使用提示

• 直接粘贴 git diff 输出，AI 自动分析并生成规范 commit
• 可以指定团队规范（如公司内部格式要求）
• 大改动建议用多行格式，小改动用单行
• 推荐：在 commit 前使用，帮助组织提交粒度

一句话原则

一个好的 commit message = 标题说明做了什么，正文说明为什么做。 未来回溯时，你会感谢写 commit 的自己。