--- name: git-commit description: 当用户明确要求"提交 Git 改动"、"生成 commit 信息"或"创建 git commit"时使用。仅用 Git 分析改动并自动生成 conventional commit 信息（可选 emoji）；必要时建议拆分提交，默认运行本地 Git 钩子（可 --no-verify 跳过），提交后默认自动 push（可 --no-push 跳过）。 metadata: author: Bensz Conan short-description: 仅用 Git 分析改动并生成 conventional commit 信息（可选 emoji），默认自动 push keywords: - git-commit - git commit - conventional commit - commit message category: normal --- # Git Commit ## 与 bensz-collect-bugs 的协作约定 - 因本 skill 设计缺陷导致的 bug，先用 `bensz-collect-bugs` 规范记录到 `~/.bensz-skills/bugs/`，不要直接修改用户本地已安装的 skill 源码；若有 workaround，先记 bug，再继续完成任务。 - 只有用户明确要求“report bensz skills bugs”等公开上报时，才用本地 `gh` 上传新增 bug 到 `huangwb8/bensz-bugs`；不要 pull / clone 整个仓库。仅用 Git 分析改动并自动生成 conventional commit 信息（可选 emoji）；必要时建议拆分提交，默认运行本地 Git 钩子（可 --no-verify 跳过），提交后默认自动 push（可 --no-push 跳过）。 ## 工作模式本技能支持两种工作模式： | 模式 | 触发方式 | 行为特征 | |------|----------|----------| | **自动模式** | 默认（无参数） | AI 自主决策所有步骤：自动暂存、自动拆分、直接提交 | | **审核模式** | `--review` 参数 | 在关键决策点暂停，等待用户确认暂存方式、拆分建议、提交信息 | **默认使用自动模式**，因为大多数情况下 commit 的顺利提交比内容本身更重要；如不满意可直接回退。 ## 触发场景 - 用户要提交代码改动 - 需要生成符合规范的提交信息 - 需要判断是否应该拆分提交 - 需要包含 emoji 的提交信息 ## 工作流程 ### 1. 仓库/分支校验 - 通过 `git rev-parse --is-inside-work-tree` 判断是否位于 Git 仓库 - **如不在 Git 仓库**：提示 `git init` 初始化仓库后继续 - 读取当前分支/HEAD 状态： - **如处于 detached HEAD 状态**：提示风险并确认是否继续 - 检测方法：`git rev-parse --symbolic-full-name HEAD` 返回 `HEAD` - 提示内容："⚠️ 当前处于 detached HEAD 状态，提交将不属于任何分支。建议先创建分支（`git switch -c `）或切换到现有分支（`git switch `）" - **如处于 rebase/merge 冲突状态**：给出明确指导 - **检测到 Git 冲突**：当前处于 rebase/merge 冲突状态，请先处理冲突： 1. 查看冲突文件：`git status` 2. 解决冲突（编辑标记为 `<<<<<<<` 的文件） 3. 标记冲突已解决：`git add <冲突文件>` 4. 继续 rebase/merge：`git rebase --continue` 或 `git merge --continue` 5. 完成后重新运行 git-commit - 或跳过当前提交：`git rebase --skip` - 或中止 rebase/merge：`git rebase --abort` / `git merge --abort` ### 2. 改动检测 - 用 `git status --porcelain` 与 `git diff` 获取已暂存与未暂存的改动 - **如无改动**：提示 "当前无改动，无需提交"，退出 - 额外检测 **未跟踪文件（untracked）**：用 `git ls-files --others --exclude-standard` 列出未跟踪且未被忽略的文件 - 若存在未跟踪文件： - **自动模式**（默认）： - 若暂存区为空：自动执行 `git add -A`（除非传入 `--no-all` 或 `--no-untracked` 跳过） - 若暂存区非空：仅暂存未跟踪文件（除非传入 `--no-untracked` 跳过） - 先获取列表：`git ls-files --others --exclude-standard` - 再执行：`git add -- ` - 如路径可能包含空格/特殊字符：用 NUL 分隔更稳妥 - `git ls-files --others --exclude-standard -z | xargs -0 git add --` - 说明：此操作不会影响你已暂存/未暂存的其他改动，只是把“新文件”补进暂存区，避免漏提交 - **审核模式**：提示用户选择： - **选项 1**：暂存所有改动（`git add -A`） - **选项 2**：仅暂存未跟踪文件（`git add -- `） - **选项 3**：暂存部分文件（`git add ...`） - **选项 4**：取消命令，手动分组暂存后重试 - 若暂存区为空且无未跟踪文件： - **自动模式**：自动执行 `git add -A`（除非传入 `--no-all` 跳过） - **审核模式**：提示用户选择暂存方式（同上） ### 3. 拆分建议按以下决策树判断是否需要拆分提交： **1. 强制拆分条件**（任一满足则建议拆分）： - 超过规模阈值：改动行数 > 300 行或跨越目录数 > 5 个 - 多种提交类型：包含 2 种以上不同类型的改动（如 feat + fix） - 多个独立功能：改动涉及 2 个以上互不相关的功能模块 **2. 建议拆分条件**（不满足强制条件时）： - 文件类型混合：源代码 + 文档/测试在同一提交 - 可回滚性差：单个提交回滚会影响其他功能 **3. 单一提交条件**（以上都不满足）： - 改动规模适中（< 300 行） - 单一功能模块 - 单一提交类型 - 可独立回滚若检测到多组独立变更或 diff 规模过大： - **自动模式**：按分组自动执行多次提交（不询问） - **审核模式**：给出每一组的 pathspec 拆分建议，询问是否接受 ### 4. 提交信息生成 #### 格式规范遵循 Conventional Commits 规范： ``` [] ()?: