Back to Details

git-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提交。

Workflow

工作流程

Step 1: Gather context

步骤1：收集上下文信息

Run these commands to understand the current state. Use 
command git
to bypass aliases and RTK proxies.
bash
command git status
command git diff HEAD
command git branch --show-current
command git log --oneline -10
command git rev-parse --abbrev-ref origin/HEAD
The last command returns the remote default branch (e.g., 
origin/main
). Strip the 
origin/
prefix to get the branch name. If the command fails or returns a bare 
HEAD
, try:
bash
command gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
If both fail, fall back to 
main
.
If there are no changes (nothing staged, nothing modified), report that and stop.
If the current branch matches 
main
, 
master
, or the resolved default branch name, 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, 
request_user_input
in Codex, 
ask_user
in Gemini). If no question tool is available, present the options and wait for the user's reply before proceeding. If the user chooses to create a branch, derive the name from the change content and switch to it before continuing.
运行以下命令了解当前状态。使用
command git
绕过别名和RTK代理。
bash
command git status
command git diff HEAD
command git branch --show-current
command git log --oneline -10
command git rev-parse --abbrev-ref origin/HEAD
最后一条命令会返回远程默认分支（例如
origin/main
）。去掉
origin/
前缀即可得到分支名称。如果该命令失败或返回空的
HEAD
，尝试：
bash
command gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
如果两种方法都失败，默认使用
main
。
如果没有任何修改（没有暂存内容，也没有已修改文件），则告知用户并停止操作。
如果当前分支是
main
、
master
或解析得到的默认分支名称，需向用户发出警告，并询问是否要继续在此分支提交，还是先创建一个功能分支。使用平台的阻塞式提问工具（Claude Code中为
AskUserQuestion
，Codex中为
request_user_input
，Gemini中为
ask_user
）。如果没有可用的提问工具，则列出选项并等待用户回复后再继续。如果用户选择创建分支，则根据修改内容生成分支名称并切换到该分支后再继续。

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
    .
按照以下优先级顺序执行：
  1. 仓库已有的规范——如果项目说明文档（如AGENTS.md、CLAUDE.md等）已加载且指定了提交信息规范，则遵循这些规范。无需重新读取这些文件；它们会在会话开始时加载。
  2. 近期提交历史——如果没有明确的文档规范，检查步骤1中获取的最近10条提交记录。如果出现清晰的模式（例如Conventional Commit格式、工单前缀、表情符号前缀），则匹配该模式。
  3. 默认：Conventional Commit格式——如果以上两种来源都没有提供模式，则使用Conventional Commit格式：
    type(scope): description
    ，其中type可选值包括
    feat
    、
    fix
    、
    docs
    、
    refactor
    、
    test
    、
    chore
    、
    perf
    、
    ci
    、
    style
    、
    build
    。

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：暂存并提交

Stage the relevant files. Prefer staging specific files by name over 
git add -A
or 
git add .
to avoid accidentally including sensitive files (.env, credentials) or unrelated changes.
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.
Use a heredoc to preserve formatting:
bash
command git commit -m "$(cat <<'EOF'
type(scope): subject line here

Optional body explaining why this change was made,
not just what changed.
EOF
)"
暂存相关文件。优先通过文件名暂存特定文件，而非使用
git add -A
或
git add .
，以避免意外包含敏感文件（如.env、凭证文件）或无关修改。
编写提交信息：
  • 主题行：简洁、使用祈使语气，重点说明原因而非内容。遵循步骤2中确定的规范。
  • 正文（必要时添加）：对于非琐碎的修改，添加一个空行分隔的正文部分。解释修改动机、权衡因素或未来阅读者需要了解的任何信息。对于明显的单一目的修改，可省略正文。
使用here-doc保留格式：
bash
command 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 
command git status
after the commit to verify success. Report the commit hash(es) and subject line(s).
提交后运行
command git status
验证是否成功。报告提交哈希值和主题行。

Important: Use 
command git

重要提示：使用
command git

Always invoke git as 
command git
in shell commands. This bypasses shell aliases and tools like RTK (Rust Token Killer) that proxy git commands.
在shell命令中始终以
command git
的方式调用git。这可以绕过shell别名和像RTK（Rust Token Killer）这样的git代理工具。