write-conventional-commit

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Write Conventional Commit

编写Conventional Commit提交信息

Inspect Git changes and return exactly one final commit message.
检查Git变更并仅返回一条最终提交信息。

Workflow

工作流程

  • Run
    git status --short
    .
  • If there are no staged or unstaged changes, reply exactly:
    No staged or unstaged changes found.
  • Run
    git diff --staged --no-ext-diff --stat
    .
  • Run
    git diff --staged --no-ext-diff
    .
  • If the staged diff is empty but the working tree is dirty, use
    git diff --no-ext-diff --stat
    and
    git diff --no-ext-diff
    as a fallback.
  • Infer the dominant intent from the diff and write one message only.
  • Return exactly one final commit message and nothing else.
  • 运行
    git status --short
  • 如果没有暂存或未暂存的变更,精确回复:
    No staged or unstaged changes found.
  • 运行
    git diff --staged --no-ext-diff --stat
  • 运行
    git diff --staged --no-ext-diff
  • 如果暂存区的diff为空但工作区有未提交变更,则使用
    git diff --no-ext-diff --stat
    git diff --no-ext-diff
    作为备选。
  • 从diff中推断核心意图,仅编写一条提交信息。
  • 仅返回最终的提交信息,不包含其他内容。

Commit Types

提交类型

Use exactly one type from this list:
  • feat: a new feature
  • fix: a bug fix
  • docs: documentation only changes
  • style: changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • refactor: a code change that neither fixes a bug nor adds a feature
  • perf: a code change that improves performance
  • test: adding missing tests or correcting existing tests
  • build: changes that affect the build system or external dependencies
  • ci: changes to our CI configuration files and scripts
  • chore: other changes that don't modify src or test files
必须从以下列表中选择一种类型:
  • feat: 新增功能
  • fix: 修复bug
  • docs: 仅修改文档
  • style: 不影响代码含义的变更(空白字符、格式调整、缺失分号等)
  • refactor: 既不修复bug也不新增功能的代码变更
  • perf: 提升性能的代码变更
  • test: 添加缺失的测试或修正现有测试
  • build: 影响构建系统或外部依赖的变更
  • ci: 修改CI配置文件或脚本
  • chore: 其他不修改源码或测试文件的变更

Conventional Commit rules

Conventional Commit规则

  • Choose the dominant intent. DO NOT combine types.
  • DO NOT end the subject with a period.
  • If the change is breaking, mark it with
    !
    after the type or scope and include a
    BREAKING CHANGE:
    footer when additional migration detail is needed.
  • Keep the subject concise; aim for 50-72 characters.
  • Never include markdown fences, bullets, analysis, or commentary.
  • Prefer a longer commit body after the short description, providing additional contextual information about the code changes.
  • Prefer lower-case after the colon unless a proper noun or acronym requires capitalization.
  • Preserve useful trailer/footer information from the context when it is clearly present.
  • Use an optional scope only when it is obvious and genuinely helpful.
  • Write the subject in imperative mood.
  • 选择核心意图,禁止合并多种类型。
  • 主题部分结尾不要加句号。
  • 如果是破坏性变更,在类型或作用域后添加
    !
    ,当需要额外迁移细节时,需包含
    BREAKING CHANGE:
    页脚。
  • 主题部分要简洁,目标长度为50-72个字符。
  • 禁止包含markdown围栏、项目符号、分析或注释内容。
  • 建议在简短描述后添加较长的提交正文,提供代码变更的额外上下文信息。
  • 冒号后优先使用小写,除非专有名词或首字母缩写需要大写。
  • 当上下文明确包含有用的尾部/页脚信息时,予以保留。
  • 仅当作用域明确且真正有帮助时,才使用可选的作用域。
  • 主题部分使用祈使语气。