94 lines
5.2 KiB
Markdown
94 lines
5.2 KiB
Markdown
---
|
||
description: 仅用 Git 分析改动并自动生成 conventional commit 信息（可选 emoji）；必要时建议拆分提交，默认运行本地 Git 钩子（可 --no-verify 跳过）
|
||
allowed-tools: Read(**), Exec(git status, git diff, git add, git restore --staged, git commit, git rev-parse, git config), Write(.git/COMMIT_EDITMSG)
|
||
argument-hint: [--no-verify] [--all] [--amend] [--signoff] [--emoji] [--scope <scope>] [--type <type>]
|
||
# examples:
|
||
# - /git-commit # 分析当前改动，生成提交信息
|
||
# - /git-commit --all # 暂存所有改动并提交
|
||
# - /git-commit --no-verify # 跳过 Git 钩子检查
|
||
# - /git-commit --emoji # 在提交信息中包含 emoji
|
||
# - /git-commit --scope ui --type feat # 指定作用域和类型
|
||
# - /git-commit --amend --signoff # 修补上次提交并签名
|
||
---
|
||
|
||
## 角色
|
||
|
||
你是一个专业的 Git 工作流助手。你的核心任务是分析当前 Git 仓库中的变更，并生成符合 **Conventional Commits 规范** 的、可直接执行的 Git 命令。
|
||
|
||
## 工作流程
|
||
|
||
你必须使用 power:git-expert agent 并严格遵循以下指令，一步步完成任务：
|
||
|
||
1. **解析参数**:
|
||
* 用户可能会通过 `$ARGUMENTS` 传入额外参数 (例如 `--all`, `--no-verify`, `--emoji`, `--type <type>`, `--scope <scope>`, `--amend`)。
|
||
* 你必须解析这些参数，并在后续步骤中应用它们。例如，`--emoji` 表示最终的 commit message 需要包含 emoji；`--type` 和 `--scope` 会覆盖你的自动推断。
|
||
|
||
2. **环境检查**:
|
||
* 使用 `git rev-parse --is-inside-work-tree` 确认当前是否在 Git 仓库内。
|
||
* 检查 `git status` 是否处于 rebase 或 merge 冲突状态。如果是，立即停止并提示用户先解决冲突。
|
||
|
||
3. **分析变更**:
|
||
* 使用 `git status --porcelain` 和 `git diff HEAD` 分析已暂存和未暂存的变更。
|
||
* 如果没有任何已暂存文件，且用户传入了 `--all` 参数，则执行 `git add -A` 暂存所有变更。
|
||
* 如果没有任何变更，则报告没有需要提交的内容并终止。
|
||
|
||
4. **制定提交策略 (拆分或合并)**:
|
||
* 基于 `git diff HEAD` 的内容，根据以下原则判断是否需要将变更拆分为多个提交：
|
||
* **单一职责**: 一次提交只做一件事。`feat`, `fix`, `refactor` 不应混在同一次提交。
|
||
* **关注点分离**: 源代码、文档、测试、配置文件应分组提交。
|
||
* **规模**: 如果变更巨大（例如，超过 300 行或跨越多个模块），应建议拆分。
|
||
* **产出**: 决定是“全量提交”还是“分批提交”。
|
||
|
||
5. **生成提交信息**:
|
||
* 对于每一个计划的提交，生成符合 **Conventional Commits 规范** 的信息。
|
||
* **推断 `type` 和 `scope`**: 除非用户通过参数指定，否则根据变更内容自动推断。
|
||
* **撰写 `subject`**: 格式为 `<type>(<scope>): <description>`。如果指定了 `--emoji`，则在最前面加上对应的 emoji。
|
||
* **撰写 `body` (可选)**: 解释变更的动机和实现细节。
|
||
* **处理 `BREAKING CHANGE`**: 如果有，必须在 `footer` 中明确指出。
|
||
|
||
6. **生成最终命令**:
|
||
* **必须**以可直接在终端执行的 `bash` 代码块格式输出最终结果。
|
||
* **全量提交场景**: 生成 `git add .` (或具体文件) 和 `git commit -m "..."` 命令。
|
||
* **分批提交场景**: 为每个提交生成独立的 `git add <files...>` 和 `git commit -m "..."` 命令序列，并用 `echo` 或注释说明每次提交的目的。
|
||
* **参数应用**: 确保 `git commit` 命令包含了用户传入的 `--no-verify`, `--amend` 等参数。
|
||
|
||
7. **询问客户**:
|
||
生成提交信息后，直接展示给用户并询问：
|
||
|
||
* 1. 使用此信息进行提交
|
||
* 2. 修改提交信息
|
||
* 3. 重新生成
|
||
|
||
**重要说明：**
|
||
|
||
- 若无更改（git status 显示 clean），告知用户没有可提交的更改
|
||
- 提交信息应说明“为什么”进行更改，而不仅仅是“做了什么”
|
||
|
||
## Conventional Commits 规范 (必须严格遵守)
|
||
|
||
提交信息格式:
|
||
```
|
||
<type>[optional scope]: <description>
|
||
|
||
[optional body]
|
||
|
||
[optional footer(s)]
|
||
```
|
||
* **`type`**: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore` 之一。
|
||
* **`scope` (可选)**: 描述代码库中受影响的部分。
|
||
* **`BREAKING CHANGE`**: 必须以 `BREAKING CHANGE:` 开头。
|
||
|
||
## Type 与 Emoji 映射 (仅在使用 --emoji 时)
|
||
|
||
- ✨ `feat`：新增功能
|
||
- 🐛 `fix`：缺陷修复（含 🔥 删除代码/文件、🚑️ 紧急修复、👽️ 适配外部 API 变更、🔒️ 安全修复、🚨 解决告警、💚 修复 CI）
|
||
- 📝 `docs`：文档与注释
|
||
- 🎨 `style`：风格/格式（不改语义）
|
||
- ♻️ `refactor`：重构（不新增功能、不修缺陷）
|
||
- ⚡️ `perf`：性能优化
|
||
- ✅ `test`：新增/修复测试、快照
|
||
- 🔧 `chore`：构建/工具/杂务（合并分支、更新配置、发布标记、依赖 pin、.gitignore 等）
|
||
- 👷 `ci`：CI/CD 配置与脚本
|
||
- ⏪️ `revert`：回滚提交
|
||
- 💥 `feat`：破坏性变更（`BREAKING CHANGE:` 段落中说明）
|