Back to Details

ce-commit

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Git Commit

Git提交

Create a single, well-crafted git commit from the current working tree changes.
根据当前工作树的变更创建一条精心编写的git提交记录。

Context

上下文信息

On platforms other than Claude Code, skip to the "Context fallback" section below and run the command there to gather context.
In Claude Code, the five labeled sections below (Git status, Working tree diff, Current branch, Recent commits, Remote default branch) contain pre-populated data. Use them directly throughout this skill -- do not re-run these commands.
Git status: !
git status
Working tree diff: !
git diff HEAD
Current branch: !
git branch --show-current
Recent commits: !
git log --oneline -10
Remote default branch: !
git rev-parse --abbrev-ref origin/HEAD 2>/dev/null || echo '__DEFAULT_BRANCH_UNRESOLVED__'
在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__'

Context fallback

上下文备用方案

In Claude Code, skip this section — the data above is already available.
Run this single command to gather all context:
bash
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__'
在Claude Code中请跳过此部分——上述数据已就绪。
运行以下单个命令来收集所有上下文信息：
bash
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__'

Workflow

工作流程

Step 1: Gather context

步骤1：收集上下文信息

Use the context above (git status, working tree diff, current branch, recent commits, remote default branch). All data needed for this step is already available -- do not re-run those commands.
The remote default branch value returns something like 
origin/main
. Strip the 
origin/
prefix to get the branch name. If it returned 
__DEFAULT_BRANCH_UNRESOLVED__
or a bare 
HEAD
, try:
bash
gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
If both fail, fall back to 
main
.
If the git status from the context above shows a clean working tree (no staged, modified, or untracked files), report that there is nothing to commit and stop.
If the current branch from the context above is empty, the repository is in detached HEAD state. Explain that a branch is required before committing if the user wants this work attached to a branch. Ask whether to create a feature branch now. Use the platform's blocking question tool: 
AskUserQuestion
in Claude Code (call 
ToolSearch
with 
select:AskUserQuestion
first if its schema isn't loaded), 
request_user_input
in Codex, 
ask_user
in Gemini, 
ask_user
in Pi (requires the 
pi-ask-user
extension). Fall back to presenting options in chat only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question.
  • If the user chooses to create a branch, derive the name from the change content, create it with 
    git checkout -b <branch-name>
    , then run 
    git branch --show-current
    again and use that result as the current branch name for the rest of the workflow.
  • If the user declines, continue with the detached HEAD commit.
使用上述上下文信息（Git状态、工作树差异、当前分支、最近提交记录、远程默认分支）。此步骤所需的所有数据已就绪——无需重新运行这些命令。
远程默认分支的返回值类似
origin/main
。请移除
origin/
前缀以获取分支名称。如果返回值为
__DEFAULT_BRANCH_UNRESOLVED__
或裸
HEAD
，请尝试：
bash
gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
如果两种方式都失败，则回退使用
main
作为默认分支。
如果上述上下文信息中的Git状态显示工作树干净（无已暂存、已修改或未跟踪文件），请告知用户没有可提交的内容并停止流程。
如果上述上下文信息中的当前分支为空，说明仓库处于分离HEAD状态。请向用户说明，如果希望将工作内容关联到分支，需要先创建分支。询问用户是否现在创建功能分支。使用平台的阻塞式提问工具：Claude Code中使用
AskUserQuestion
（如果其架构未加载，请先调用
ToolSearch
并指定
select:AskUserQuestion
），Codex中使用
request_user_input
，Gemini中使用
ask_user
，Pi中使用
ask_user
（需要
pi-ask-user
扩展）。仅当工具集中没有阻塞式工具或调用出错时（如Codex编辑模式），才回退到在聊天中展示选项——不要因为需要加载架构而跳过提问。绝对不要静默跳过此问题。
  • 如果用户选择创建分支，请根据变更内容生成分支名称，使用
    git checkout -b <branch-name>
    创建分支，然后重新运行
    git branch --show-current
    并将结果作为后续工作流程中的当前分支名称。
  • 如果用户拒绝创建分支，则继续进行分离HEAD状态下的提交。

Step 2: Determine commit message convention

步骤2：确定提交信息规范

Follow this priority order:
  1. Repo conventions already in context -- If project instructions (AGENTS.md, CLAUDE.md, or similar) are already loaded and specify commit message conventions, follow those. Do not re-read these files; they are loaded at session start.
  2. Recent commit history -- If no explicit convention is documented, examine the 10 most recent commits from Step 1. If a clear pattern emerges (e.g., conventional commits, ticket prefixes, emoji prefixes), match that pattern.
  3. Default: conventional commits -- If neither source provides a pattern, use conventional commit format: 
    type(scope): description
    where type is one of 
    feat
    , 
    fix
    , 
    docs
    , 
    refactor
    , 
    test
    , 
    chore
    , 
    perf
    , 
    ci
    , 
    style
    , 
    build
    .
When using conventional commits, choose the type that most precisely describes the change (the type list above). Where 
fix:
and 
feat:
both seem to fit, default to 
fix:
: a change that remedies broken or missing behavior is 
fix:
even when implemented by adding code. Reserve 
feat:
for capabilities the user could not previously accomplish. Other types remain primary when they fit better. The user may override for a specific change.
请按照以下优先级顺序执行：
  1. 仓库已有的规范——如果已加载项目说明文档（如AGENTS.md、CLAUDE.md等）且其中指定了提交信息规范，请遵循该规范。无需重新读取这些文件；它们已在会话开始时加载。
  2. 最近提交历史——如果没有明确的文档规范，请检查步骤1中获取的最近10条提交记录。如果出现清晰的模式（如规范式提交、工单前缀、表情符号前缀），请匹配该模式。
  3. 默认：规范式提交——如果上述两种来源都未提供模式，请使用规范式提交格式：
    type(scope): description
    ，其中type可选值为
    feat
    、
    fix
    、
    docs
    、
    refactor
    、
    test
    、
    chore
    、
    perf
    、
    ci
    、
    style
    、
    build
    。
使用规范式提交时，请选择最能准确描述变更的type（上述type列表）。当
fix:
和
feat:
似乎都适用时，默认使用
fix:
：修复损坏或缺失功能的变更即使是通过添加代码实现的，也应归类为
fix:
。仅当用户之前无法完成某项功能时，才使用
feat:
。其他type在更适合时优先使用。用户可针对特定变更覆盖此规则。

Step 3: Consider logical commits

步骤3：考虑逻辑提交分组

Before staging everything together, scan the changed files for naturally distinct concerns. If modified files clearly group into separate logical changes (e.g., a refactor in one directory and a new feature in another, or test files for a different change than source files), create separate commits for each group.
Keep this lightweight:
  • Group at the file level only -- do not use 
    git add -p
    or try to split hunks within a file.
  • If the separation is obvious (different features, unrelated fixes), split. If it's ambiguous, one commit is fine.
  • Two or three logical commits is the sweet spot. Do not over-slice into many tiny commits.
在暂存所有变更之前，请扫描已修改文件，查看是否存在自然区分的不同关注点。如果已修改文件明显可分为独立的逻辑变更组（如一个目录中的重构和另一个目录中的新功能，或与源文件变更无关的测试文件变更），请为每个组创建单独的提交记录。
请保持此操作轻量化：
  • 仅在文件级别进行分组——不要使用
    git add -p
    或尝试拆分文件内的代码块。
  • 如果区分明显（不同功能、不相关的修复），则拆分提交。如果区分模糊，使用单个提交即可。
  • 2到3个逻辑提交是最佳选择。不要过度拆分成大量微小的提交。

Step 4: Stage and commit

步骤4：暂存并提交

If the current branch from the context above is 
main
, 
master
, or the resolved default branch from Step 1, warn the user and ask whether to continue committing here or create a feature branch first. Use the platform's blocking question tool: 
AskUserQuestion
in Claude Code (call 
ToolSearch
with 
select:AskUserQuestion
first if its schema isn't loaded), 
request_user_input
in Codex, 
ask_user
in Gemini, 
ask_user
in Pi (requires the 
pi-ask-user
extension). Fall back to presenting options in chat only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question. If the user chooses to create a branch, derive the name from the change content, create it with 
git checkout -b <branch-name>
, then continue.
Write the commit message:
  • Subject line: Concise, imperative mood, focused on why not what. Follow the convention determined in Step 2.
  • Body (when needed): Add a body separated by a blank line for non-trivial changes. Explain motivation, trade-offs, or anything a future reader would need. Omit the body for obvious single-purpose changes.
For each commit group, stage and commit in a single call. Prefer staging specific files by name over 
git add -A
or 
git add .
to avoid accidentally including sensitive files (.env, credentials) or unrelated changes. Use a heredoc to preserve formatting:
bash
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
)"
如果步骤1中获取的当前分支为
main
、
master
或解析后的默认分支，请向用户发出警告，并询问是否继续在此分支提交，还是先创建功能分支。使用平台的阻塞式提问工具：Claude Code中使用
AskUserQuestion
（如果其架构未加载，请先调用
ToolSearch
并指定
select:AskUserQuestion
），Codex中使用
request_user_input
，Gemini中使用
ask_user
，Pi中使用
ask_user
（需要
pi-ask-user
扩展）。仅当工具集中没有阻塞式工具或调用出错时（如Codex编辑模式），才回退到在聊天中展示选项——不要因为需要加载架构而跳过提问。绝对不要静默跳过此问题。如果用户选择创建分支，请根据变更内容生成分支名称，使用
git checkout -b <branch-name>
创建分支，然后继续流程。
编写提交信息：
  • 主题行：简洁、使用祈使语气，重点说明为什么变更，而非变更了什么。遵循步骤2中确定的规范。
  • 正文（必要时）：对于非琐碎的变更，添加与主题行空一行分隔的正文。解释变更动机、权衡因素或未来读者需要了解的任何信息。对于明显单一用途的变更，可省略正文。
对于每个提交组，在单个调用中完成暂存和提交。优先通过文件名暂存特定文件，而非使用
git add -A
或
git add .
，以避免意外包含敏感文件（如.env、凭据）或无关变更。使用here-doc保留格式：
bash
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
)"

Step 5: Confirm

步骤5：确认

Run 
git status
after the commit to verify success. Report the commit hash(es) and subject line(s).
提交完成后运行
git status
以验证是否成功。报告提交哈希值和主题行。