关于 git-commit
此技能根据当前工作树创建整理妥当的 Git 提交。它检查仓库上下文与提交惯例，将明显不同的变更分组提交，并验证结果。
主要功能
- 01检查状态和工作树差异
- 02遵循仓库提交惯例
- 03将不同变更分组成提交
- 04验证提交和最终状态
适用场景
- 01提交一组已完成的变更
- 02将无关变更拆分为逻辑提交
- 03检查提交结果和仓库状态
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/git-commit确认已加载。
详细介绍
Git Commit
根据当前工作树中的更改，创建一个精心编写的 Git 提交。
上下文
如果你不是 Claude Code，请跳到下面的“上下文回退”部分，并运行其中的命令来收集上下文。
如果你是 Claude Code，下面五个标记部分（Git 状态、工作树差异、当前分支、最近提交、远程默认分支）包含预先填充的数据。在整个技能中直接使用这些数据——不要重新运行这些命令。
Git 状态：
!git status
工作树差异：
!git diff HEAD
当前分支：
!git branch --show-current
最近提交：
!git log --oneline -10
远程默认分支：
!git rev-parse --abbrev-ref origin/HEAD 2>/dev/null || echo '__DEFAULT_BRANCH_UNRESOLVED__'
上下文回退
如果你是 Claude Code，请跳过此部分——上面的数据已可用。
运行以下单条命令以收集所有上下文：
printf '=== STATUS ===\n'; git status; printf '\n=== DIFF ===\n'; git diff HEAD; printf '\n=== BRANCH ===\n'; git branch --show-current; printf '\n=== LOG ===\n'; git log --oneline -10; printf '\n=== DEFAULT_BRANCH ===\n'; git rev-parse --abbrev-ref origin/HEAD 2>/dev/null || echo '__DEFAULT_BRANCH_UNRESOLVED__'
工作流
步骤 1：收集上下文
使用上文的上下文（Git 状态、工作树差异、当前分支、最近提交、远程默认分支）。此步骤所需的所有数据均已可用——不要重新运行这些命令。
远程默认分支的值会返回类似 origin/main 的内容。去掉 origin/ 前缀即可得到分支名称。如果返回 __DEFAULT_BRANCH_UNRESOLVED__ 或单独的 HEAD，请尝试：
gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
如果两种方法都失败，则回退到 main。
如果上文的 Git 状态显示工作树干净（没有暂存、修改或未跟踪的文件），请报告没有内容需要提交，然后停止。
如果上文的当前分支为空，则仓库处于分离 HEAD 状态。如果用户希望将此工作关联到某个分支，请说明提交前需要有一个分支。询问是否现在创建功能分支。使用平台提供的阻塞式提问工具（Claude Code 中的 AskUserQuestion、Codex 中的 request_user_input、Gemini 中的 ask_user）。如果没有可用的提问工具，请列出选项并等待用户回复后再继续。
- 如果用户选择创建分支，根据更改内容推导名称，使用
git checkout -b <branch-name>创建分支，然后再次运行git branch --show-current，并在后续工作流中使用该结果作为当前分支名称。 - 如果用户拒绝，则继续在分离 HEAD 状态下提交。
步骤 2：确定提交消息规范
按以下优先顺序处理：
- 上下文中已有的仓库规范——如果项目说明（AGENTS.md、CLAUDE.md 或类似文件）已加载，并指定了提交消息规范，则遵循该规范。不要重新读取这些文件；它们已在会话开始时加载。
- 最近的提交历史——如果没有明确记录的规范，请查看步骤 1 中的最近 10 条提交。如果存在明显的模式（例如 conventional commits、工单前缀、表情符号前缀），则遵循该模式。
- 默认：conventional commits——如果以上来源均未提供模式，则使用 conventional commit 格式：
type(scope): description，其中 type 为feat、fix、docs、refactor、test、chore、perf、ci、style、build之一。
步骤 3：考虑逻辑提交
在一次性暂存所有内容之前，检查更改的文件，看看是否存在自然区分的事项。如果修改的文件明显可归为不同的逻辑更改（例如，一个目录中的重构与另一个目录中的新功能，或与源文件更改无关的测试文件），则分别创建提交。
保持精简：
- 只在文件级别分组——不要使用
git add -p，也不要尝试拆分文件内的差异块。 - 如果区分很明显（不同功能、无关修复），就拆分。如果不确定，一次提交即可。
- 两到三个逻辑提交最合适。不要拆分成许多很小的提交。
步骤 4：暂存并提交
如果上文中的当前分支是 main、master 或步骤 1 中确定的默认分支，请提醒用户，并询问是继续在此分支提交，还是先创建功能分支。使用平台的阻塞式提问工具（Claude Code 中的 AskUserQuestion、Codex 中的 request_user_input、Gemini 中的 ask_user）。如果没有可用的提问工具，请提供选项并等待用户回复后再继续。如果用户选择创建分支，请根据更改内容确定分支名称，使用 git checkout -b <branch-name> 创建分支，然后继续。
编写提交消息：
- 主题行：简洁，使用祈使语气，侧重于原因而不是内容。遵循步骤 2 中确定的约定。
- 正文（必要时）：对于非简单更改，在空行后添加正文。说明动机、权衡，或未来读者需要了解的信息。对于显而易见的单一用途更改，省略正文。
对于每组提交，在一次调用中完成暂存和提交。优先按名称暂存特定文件，而不是使用 git add -A 或 git add .，以避免意外包含敏感文件（.env、凭据）或无关更改。使用 heredoc 保留格式：
git add file1 file2 file3 && git commit -m "$(cat <<'EOF'
type(scope): subject line here
Optional body explaining why this change was made,
not just what changed.
EOF
)"
步骤 5：确认
提交后运行 git status 以确认成功。报告提交哈希和主题行。