Back to Details

commit

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Context

背景信息

  • Staged diff: !
    git diff --staged
  • Branch: !
    git branch --show-current
  • Recent commits: !
    git log --oneline -5
  • 暂存区差异：!
    git diff --staged
  • 当前分支：!
    git branch --show-current
  • 最近提交记录：!
    git log --oneline -5

Your task

你的任务

Create a single git commit from the staged changes only.
仅从已暂存的变更中创建一个Git提交。

Pre-flight checks

前置检查

  1. If there are no staged changes, stop immediately and tell the user to stage files first. Do nothing else.
  2. Never run 
    git add
    . Never run 
    git push
    . Only commit what is already staged.
  1. 如果没有已暂存的变更，立即停止操作并告知用户先暂存文件，不执行其他任何操作。
  2. 永远不要运行
    git add
    命令，永远不要运行
    git push
    命令。仅提交已暂存的内容。

Commit message format

提交消息格式

Follow Conventional Commits (
https://www.conventionalcommits.org/en/v1.0.0/
):
<type>(<optional scope>): <description>

[optional body]
Types:
  • feat – new capability
  • fix – bug fix
  • docs – documentation only
  • refactor – restructuring without functional change
  • test – test creation or modification
  • chore – routine maintenance (including dependencies)
  • build – build system or external dependencies
  • perf – performance improvement
  • ci – CI/CD changes
Append 
!
after the type/scope for breaking changes (e.g. 
feat!: change API response format
).
遵循Conventional Commits规范（
https://www.conventionalcommits.org/en/v1.0.0/
）：
<type>(<optional scope>): <description>

[optional body]
类型说明：
  • feat – 新增功能
  • fix – 修复Bug
  • docs – 仅修改文档
  • refactor – 代码重构（无功能变化）
  • test – 创建或修改测试用例
  • chore – 日常维护（包括依赖更新）
  • build – 构建系统或外部依赖变更
  • perf – 性能优化
  • ci – CI/CD流程变更
如果是破坏性变更，在类型/作用域后添加
!
（例如：
feat!: change API response format
）。

Rules

规则

  • Infer the correct type from the diff.
  • Write a concise description (lowercase, imperative mood, no period).
  • Add a body only when the diff is non-trivial and the "why" isn't obvious from the description.
  • Body: wrap at 72 characters, explain why not what.
  • Match the style and tone of the recent commits shown above.
  • Use a HEREDOC to pass the message to 
    git commit -m
    .
  • Do not send any text besides the tool calls.
  • 根据差异内容推断正确的提交类型。
  • 撰写简洁的描述（小写、祈使语气、无句号）。
  • 仅当差异内容非琐碎且无法从描述中明确“原因”时，才添加正文部分。
  • 正文：每行不超过72个字符，解释原因而非内容。
  • 与上方展示的最近提交记录的风格和语气保持一致。
  • 使用HEREDOC将消息传递给
    git commit -m
    命令。
  • 除工具调用外，不要发送任何其他文本。