Commit Message Generator

目标

自动读取暂存区变更，生成一条最优的 Conventional Commits 格式 commit message（中文描述）， 经用户确认后执行提交。不满意可反复修改，直到满意为止。

工作流程

第一步：确认 diff 范围

若用户未明确指定范围，先询问：

请问要基于哪些变更生成 commit message？
  1. 仅暂存区（git diff --staged）— 默认推荐
  2. 全部未提交变更（git diff HEAD）

• 用户选 1 或直接回车 → 运行 git diff --staged
• 用户选 2 或说"全部"/"所有变更" → 运行 git diff HEAD
• 若用户已粘贴 diff 内容 → 直接使用，跳过此步
• 若用户在触发时已说明范围（如"staged 的变更"、"暂存的变更"、"所有改动"）→ 直接按其意图执行，无需再问

获取 diff 后：

• 若 diff 为空：提示"没有检测到变更，请确认文件已修改或已 git add"，流程结束
• diff 较长时：抓住关键变更即可，无需逐行分析

第二步：判断是否需要分批提交

扫描所有变更文件，按模块路径 + 变更性质双维度评估：

• 单批：所有文件属于同一模块，或虽跨模块但属于同一次整体改动（如全局重构、统一升级依赖）
• 多批：文件跨多个无关模块，且各模块的变更性质不同（如同时有新功能和 bug 修复）

若判断为多批，展示分组方案：

检测到变更跨多个模块，建议分批提交：

  批次 1：internal/auth/（新增登录接口）
  批次 2：internal/order/（修复库存扣减 bug）
  批次 3：docs/（更新 API 文档）

选择方式：
  输入批次编号（如 1）→ 先提交该批次
  输入 all → 合并为一条 commit 一次提交

• 用户选择某批次 → 运行 git add <该批次的文件> 暂存，然后继续第三步生成该批次的 message
• 用户选 all → 直接进入第三步，生成一条概括性 message
• 若原本已是暂存区 diff 且已有明确的 add 范围，尊重用户已有的暂存状态，不强制拆分

第三步：分析变更，生成 commit message

按以下顺序思考：

1. 扫描文件路径 → 确定 scope（模块名）
2. 识别变更性质 → 新增 / 删除 / 修改了什么
3. 判断 type → 参考下方类型表
4. 提炼一句话描述 → 聚焦最核心改动，忽略次要细节
5. 判断是否需要 body → 原因不明显时补充说明

第四步：展示并等待确认

用以下格式展示结果，清晰简洁：

已生成 commit message：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━
feat(user): 新增用户注册接口
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

直接回车或输入 y → 确认提交
输入修改意见 → 重新生成

第四步：根据用户反馈处理

用户确认（y / 回车 / "好" / "可以" / "提交"）：

1. 执行 git commit -m "<message>"，记录返回的 commit hash

2. 执行 git push，根据结果处理：

   push 成功 → 告知提交完成，附上 commit hash 和远端分支名

   push 失败：新分支无上游（stderr 含 --set-upstream 或 no upstream）：

   • 自动改用 git push -u origin <当前分支名> 重试
   • 成功则告知；仍失败则提示错误信息让用户处理

   push 失败：远端有新提交（stderr 含 rejected 或 fetch first）：

   • 提示用户："远端有新提交，需要先同步。建议运行 git pull --rebase，完成后重新 push。"
   • 询问是否自动执行 git pull --rebase && git push

   其他 push 失败 → 原样输出错误信息，告知 commit 已成功但 push 失败，用户可手动处理

用户提出修改意见：

• 有具体意见（如"scope 改成 api"、"描述太长了"）→ 针对性调整后重新生成
• 只说"不好"或"重新来"→ 换角度重新分析 diff，生成不同表达的 message
• 回到第四步，再次展示并等待确认

循环：反复执行直到用户确认提交，或明确表示放弃。

输出格式

<type>(<scope>): <中文简短描述>

[可选 body：每行不超过 72 字，说明"做了什么"和"为什么"]

类型（type）选择规则

scope 提取规则

• 从 diff 文件路径推断，取最能代表变更的模块名
• 例：internal/auth/handler.go → scope 为 auth
• 若变更跨多个无关模块，scope 可省略

描述写作规则

• 中文，动词开头（"新增"、"修复"、"优化"、"重构"）
• 不超过 50 字
• 不写"代码"、"逻辑"等废话，直接说做了什么
• 不以句号结尾

Body 写作规则（可选）

• 仅当改动较复杂、原因不显而易见时才写
• 说明"为什么这样改"，不是逐行复述 diff
• 中文，每行 ≤ 72 字

示例

示例 1：新增 API 接口

diff 摘要：internal/user/handler.go 新增 CreateUser 函数及路由注册

输出：

feat(user): 新增创建用户接口

示例 2：修复 bug + 需要解释原因

diff 摘要：internal/order/service.go 修复并发场景下的库存扣减问题

输出：

fix(order): 修复并发扣减库存时的数据竞争问题

高并发场景下多个 goroutine 同时读写库存字段，导致超卖。
改用 SELECT FOR UPDATE 加行锁确保原子性。

示例 3：重构

diff 摘要：将 pkg/db 中多处重复的事务处理代码抽取为公共函数

输出：

refactor(db): 抽取事务处理为公共辅助函数

注意事项

• 优先自动运行 git diff --staged；若用户已粘贴 diff 则使用用户提供的内容
• diff 为空时直接告知，不瞎猜
• 只输出一条最优结果，不提供多个候选
• 执行 git commit 前必须获得用户明确确认
• 结果展示时不要加多余的解释文字，用户只需要能直接确认的 message
• 若用户明确指定了 scope 或 type，优先尊重用户意图