Back to Details

commit-workflow

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Commit Workflow

提交工作流

Use this skill when the user asks to create a commit from current repository changes.
当用户要求基于当前仓库变更创建提交时，使用本Skill。

Output Goal

输出目标

Create exactly one local git commit that includes only intended files and uses a concise Conventional Commits-style subject. Do not push.
创建恰好一个本地git提交，仅包含指定文件，并使用简洁的Conventional Commits风格的主题。不要执行推送操作。

Commit Message Format

Commit信息格式

<type>(<scope>): <summary>
  • type
    REQUIRED.
    • Use 
      feat
      for new user-facing features.
    • Use 
      fix
      for bug fixes.
    • Common alternatives: 
      docs
      , 
      refactor
      , 
      chore
      , 
      test
      , 
      perf
      , 
      build
      , 
      ci
      .
  • scope
    OPTIONAL. Keep it short and noun-like (examples: 
    api
    , 
    parser
    , 
    ui
    , 
    git
    ).
  • summary
    REQUIRED.
    • Imperative mood.
    • <= 72 chars.
    • No trailing period.
<type>(<scope>): <summary>
  • type
    为必填项。
    • 新增面向用户的功能时使用
      feat
      。
    • 修复Bug时使用
      fix
      。
    • 常见替代类型：
      docs
      、
      refactor
      、
      chore
      、
      test
      、
      perf
      、
      build
      、
      ci
      。
  • scope
    为可选项。需简短且为名词形式（示例：
    api
    、
    parser
    、
    ui
    、
    git
    ）。
  • summary
    为必填项。
    • 使用祈使语气。
    • 长度不超过72个字符。
    • 末尾不加句号。

Rules

规则

  • Body is optional. If needed, insert a blank line after the subject.
  • Do not add breaking-change markers/footers.
  • Do not add sign-offs.
  • Commit only. Never push.
  • If file inclusion is ambiguous, ask the user which files to include before committing.
  • Never include likely secrets (
    .env
    , key files, credentials) unless user explicitly requests it.
  • 正文为可选项。若需要，在主题后插入一个空行。
  • 不要添加破坏性变更标记/页脚。
  • 不要添加签署信息。
  • 仅执行提交操作，绝不推送。
  • 若文件包含范围不明确，在提交前询问用户应包含哪些文件。
  • 除非用户明确要求，否则绝不包含可能的敏感文件（如
    .env
    、密钥文件、凭证）。

Procedure

操作步骤

  1. Inspect repository state: 
    • git status
    • git diff
    • git diff --staged
  2. Optionally inspect recent subject style: 
    • git log -n 50 --pretty=format:%s
  3. Decide the file set to commit:
    • If unambiguous, proceed.
    • If ambiguous, ask user which files to include.
  4. Stage only intended files.
  5. Draft a concise subject reflecting why the change exists.
  6. Create one commit.
  7. Verify final state with 
    git status
    and report:
    • commit hash
    • subject
    • staged/unstaged leftovers (if any)
  1. 检查仓库状态： 
    • git status
    • git diff
    • git diff --staged
  2. （可选）检查近期提交主题风格： 
    • git log -n 50 --pretty=format:%s
  3. 确定要提交的文件集：
    • 若范围明确，直接继续。
    • 若范围不明确，询问用户应包含哪些文件。
  4. 仅暂存指定文件。
  5. 撰写简洁的主题，说明变更的原因。
  6. 创建一个提交。
  7. 使用
    git status
    验证最终状态并报告：
    • 提交哈希值
    • 提交主题
    • 暂存/未暂存的剩余变更（若有）

Failure Handling

故障处理

  • If commit fails due to hooks, inspect hook output and fix the issue.
  • After fixing, create a new commit (do not amend unless user asked to amend).
  • If there are no changes to commit, report that clearly and do not create an empty commit.
  • 若提交因钩子失败，检查钩子输出并修复问题。
  • 修复后创建新的提交（除非用户要求修改，否则不要使用amend）。
  • 若没有可提交的变更，清晰告知用户，不要创建空提交。

Quick Reference

快速参考

bash
git status
git diff
git diff --staged
git log -n 50 --pretty=format:%s
git add <paths>
git commit -m "<type>(<scope>): <summary>"
git status
bash
git status
git diff
git diff --staged
git log -n 50 --pretty=format:%s
git add <paths>
git commit -m "<type>(<scope>): <summary>"
git status