Back to Details

commit-assistant

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Git Commit Assistant

Git提交助手

Create general-purpose Commit, PR, and release notes text.
创建通用的提交、PR和发布说明文本。

Workflow

工作流程

  1. Read any project-specific rules (if provided).
  2. Collect change context: 
    git status -sb
    , 
    git diff --stat
    , 
    git diff
    .
  3. Determine the primary change type.
  4. Ask only for missing inputs:
    • What changed and why
    • Breaking change status
    • Release notes need, audience, and category
    • Issue/Epic/Tracking reference (if the project uses them)
  5. Produce Commit/PR/Release notes and validate.
  1. 阅读项目特定规则（如果提供）。
  2. 收集变更上下文：
    git status -sb
    , 
    git diff --stat
    , 
    git diff
    .
  3. 确定主要变更类型。
  4. 仅询问缺失的输入信息：
    • 变更内容及原因
    • 是否为破坏性变更
    • 是否需要发布说明、目标受众及分类
    • 问题/史诗/跟踪引用（如果项目使用）
  5. 生成提交/PR/发布说明并进行验证。

Commit rules

提交规则

  • Format: 
    type: Subject
  • Suggested 
    type
    : 
    feat
    fix
    docs
    style
    refactor
    test
    chore
    revert
  • Subject rules (seven rules):
    • Separate subject from body with a blank line
    • Limit subject line to 50 characters
    • Capitalize the subject line
    • Do not end the subject line with a period
    • Use imperative mood
  • Body rules:
    • Explain what and why, not how
    • Wrap at 72 characters per line (hard max 100)
    • Use English, imperative
  • Breaking changes:
    • Use 
      type!: Subject
      or
    • Add footer 
      BREAKING CHANGE: ...
  • Add issue references only if the project uses them (e.g., 
    Refs: #123
    )
  • 🔒 Never include secrets or credentials
  • 格式：
    type: Subject
  • 推荐的
    type
    类型：
    feat
    fix
    docs
    style
    refactor
    test
    chore
    revert
  • 主题规则（七条）：
    • 主题与正文之间用空行分隔
    • 主题行长度限制为50个字符
    • 主题行首字母大写
    • 主题行末尾不加句号
    • 使用祈使语气
  • 正文规则：
    • 仅说明变更内容及原因，无需说明实现方式
    • 每行最多72个字符（硬上限100）
    • 使用英文、祈使语气
  • 破坏性变更：
    • 使用
      type!: Subject
      格式，或
    • 添加页脚
      BREAKING CHANGE: <Impact>
      # 仅在需要时使用
  • 仅当项目要求时添加问题引用（例如：
    Refs: #123
    ）
  • 🔒 绝对不要包含密钥或凭证

PR rules

PR规则

  • Title: short imperative phrase, no period
  • Description must answer:
    • What changed?
    • Why?
    • Breaking changes?
  • Reuse Commit Subject when appropriate
  • 标题：简短的祈使句短语，末尾不加句号
  • 描述必须回答以下问题：
    • 变更了什么？
    • 为什么变更？
    • 是否存在破坏性变更？
  • 合适时可复用提交主题

Release notes rules

发布说明规则

  • Include only user-facing changes
  • Use 
    Release notes: None
    for internal refactors/tests/infra
  • Prefer categories when useful: Added / Changed / Fixed / Breaking / Security / Performance
  • Describe what changed, why it matters, and how users notice it
  • 🔒 Never include secrets or private data
  • 仅包含面向用户的变更内容
  • 对于内部重构/测试/基础设施变更，使用
    Release notes: None
  • 必要时优先使用分类：新增/变更/修复/破坏性/安全/性能
  • 说明变更内容、重要性以及用户会如何感知到该变更
  • 🔒 绝对不要包含机密或私有数据

Output templates

输出模板

Commit:
<type>: <Subject>

<What changed.>
<Why it changed.>

BREAKING CHANGE: <Impact>  # only if needed
PR:
<Title>

What changed
- ...

Why
- ...

Breaking changes
- None | ...
Release notes:
Release notes: None
提交信息：
<type>: <Subject>

<变更内容。>
<变更原因。>

BREAKING CHANGE: <Impact>  # only if needed
PR：
<标题>

变更内容
- ...

原因
- ...

破坏性变更
- 无 | ...
发布说明：
Release notes: None

or

or

Release notes (Added): ... Release notes (Fixed): ... Release notes (Breaking): ...
undefined
Release notes (Added): ... Release notes (Fixed): ... Release notes (Breaking): ...
undefined

Validation checklist

验证检查清单

  • Subject length <= 50, imperative, capitalized, no period
  • Blank line between subject and body
  • Body lines wrap at 72 (<= 100)
  • Body explains what/why only
  • No secrets or private data 🔒
  • 主题长度 ≤ 50字符，使用祈使语气、首字母大写、末尾无句号
  • 主题与正文之间有空行
  • 正文每行换行不超过72字符（≤100）
  • 正文仅说明变更内容及原因
  • 不包含机密或私有数据 🔒