conventional-commits

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Conventional Commits

Use this skill to produce commit messages that follow the Conventional Commits 1.0.0 specification. Use the official spec as the source of truth: https://www.conventionalcommits.org/en/v1.0.0/#specification

使用本技能生成符合Conventional Commits 1.0.0规范的提交信息。请以官方规范为权威参考：https://www.conventionalcommits.org/en/v1.0.0/#specification

Output Format

输出格式

Write commit messages in this structure:

text

<type>[optional scope][optional !]: <description>

[optional body]

[optional footer(s)]

Apply these REQUIRED rules:

Start with a type, then optional scope, optional
```
!
```
, then
```
: 
```
.
Use
```
feat
```
for new features.
Use
```
fix
```
for bug fixes.
Put scope in parentheses when used, e.g.
```
fix(parser):
```
.
Place the description immediately after
```
: 
```
.
Start body one blank line after the description.
Start footer block one blank line after body (or after description if no body).
Format each footer as
```
<token>: <value>
```
or
```
<token> #<value>
```
.
Use
```
-
```
in footer tokens instead of spaces, except
```
BREAKING CHANGE
```
.
Mark breaking changes with
```
!
```
before
```
:
```
and/or
```
BREAKING CHANGE: <description>
```
footer.
Keep
```
BREAKING CHANGE
```
uppercase when used.
Treat other structural units as case-insensitive when validating.

Apply these RECOMMENDED quality rules:

Write the description in imperative mood (for example
```
fix auth timeout
```
, not
```
fixed auth timeout
```
).
Keep the description concise so the header is easy to scan in
```
git log
```
.
Wrap body/footer lines at about 72 characters for terminal readability.
Use a body to explain why the change is needed when intent is not obvious from the diff.
Use explicit issue/action trailers when relevant (for example
```
Fixes: #123
```
,
```
Resolves: #77
```
,
```
Refs: #42
```
).

请按照以下结构撰写提交信息：

text

<type>[可选 scope][可选 !]: <描述>

[可选 正文]

[可选 页脚]

Type Selection

强制规则

Choose one primary type that best matches intent:

```
feat
```
: add behavior or capability
```
fix
```
: correct incorrect behavior
```
docs
```
: documentation-only change
```
style
```
: formatting-only change
```
refactor
```
: internal change without behavior fix/feature
```
perf
```
: performance improvement
```
test
```
: add or change tests
```
build
```
: build/dependency/tooling change
```
ci
```
: CI/CD pipeline change
```
chore
```
: maintenance that does not fit above
```
revert
```
: revert a previous change

Use types outside

feat

and

fix

when appropriate; only

feat

fix

, and breaking markers imply SemVer meaning by default.

以类型开头，后跟可选的范围、可选的
```
!
```
，再跟
```
: 
```
。
新增功能使用
```
feat
```
类型。
修复Bug使用
```
fix
```
类型。
使用范围时需放在括号内，例如
```
fix(parser):
```
。
描述内容紧跟在
```
: 
```
之后。
正文需在描述后空一行开始。
页脚块需在正文后空一行开始（若没有正文，则在描述后空一行）。
每个页脚格式为
```
<标识>: <内容>
```
或
```
<标识> #<内容>
```
。
页脚标识中使用
```
-
```
代替空格，
```
BREAKING CHANGE
```
除外。
破坏性变更需在
```
: 
```
前添加
```
!
```
，和/或使用
```
BREAKING CHANGE: <描述>
```
页脚标记。
使用
```
BREAKING CHANGE
```
时需保持大写。
验证时，其他结构单元不区分大小写。

Drafting Workflow

Validation Checklist

类型选择

Confirm all items before returning a commit message:

Header matches
```
<type>[scope][!]: <description>
```
.
Description exists and is not empty.
Body and footer blocks are separated by exactly one blank line.
Footer tokens are valid trailers.
Breaking changes are explicitly marked (
```
!
```
or
```
BREAKING CHANGE:
```
).
```
feat
```
/
```
fix
```
are used correctly when applicable.
Description uses imperative wording and is concise.
Body/footers are wrapped for readability when multi-line.

选择最符合变更意图的主类型：

```
feat
```
: 添加新行为或功能
```
fix
```
: 修正错误行为
```
docs
```
: 仅文档变更
```
style
```
: 仅格式调整
```
refactor
```
: 内部代码重构，无功能修复或新增
```
perf
```
: 性能优化
```
test
```
: 添加或修改测试
```
build
```
: 构建/依赖/工具链变更
```
ci
```
: CI/CD流水线变更
```
chore
```
: 不属于以上类型的维护操作
```
revert
```
: 回滚之前的变更

适当时使用

feat

和

fix

之外的类型；默认情况下，只有

feat

、

fix

和破坏性变更标记会关联SemVer版本含义。

SemVer Mapping

撰写流程

```
fix
```
-> PATCH
```
feat
```
-> MINOR
Any commit with breaking change marker -> MAJOR

用一句话总结变更内容及原因。
判断变更属于功能新增、Bug修复还是其他类型。
若能明确影响范围，选择范围名词（如
```
api
```
、
```
auth
```
、
```
parser
```
、
```
deps
```
）。
检测是否为破坏性变更：
- 在
```
: 
```
  前添加
```
!
```
  ，和/或
- 添加
```
BREAKING CHANGE: <描述>
```
  页脚。
撰写简洁的描述行。
描述使用祈使语气，且可独立理解。
仅当需要额外上下文时添加正文段落，每行约72个字符换行。
为元数据添加页脚标记（例如
```
Fixes: #123
```
、
```
Reviewed-by: Name
```
）。
最终确定前对照下方检查清单进行复核。

Examples

验证检查清单

text

feat(auth): add device-bound refresh tokens

text

fix(api): prevent duplicate invoice creation

Add idempotency key validation for create-invoice endpoint.

Refs: #482

text

feat(storage)!: replace v1 blob schema

BREAKING CHANGE: remove support for legacy v1 blob readers.

返回提交信息前请确认所有项：

信息头符合
```
<type>[scope][!]: <描述>
```
格式。
描述存在且不为空。
正文和页脚块之间恰好空一行。
页脚标识为有效的标记格式。
破坏性变更已明确标记（
```
!
```
或
```
BREAKING CHANGE:
```
）。
适当时正确使用
```
feat
```
/
```
fix
```
类型。
描述使用祈使语气且简洁。
多行的正文/页脚已换行以提升可读性。

—

SemVer版本映射

—

```
fix
```
-> PATCH版本
```
feat
```
-> MINOR版本
任何带有破坏性变更标记的提交 -> MAJOR版本

—

示例

—

text

feat(auth): add device-bound refresh tokens

text

fix(api): prevent duplicate invoice creation

Add idempotency key validation for create-invoice endpoint.

Refs: #482

text

feat(storage)!: replace v1 blob schema

BREAKING CHANGE: remove support for legacy v1 blob readers.

conventional-commits

Original

Translation

Conventional Commits

Conventional Commits

Output Format

输出格式

Type Selection

强制规则

Drafting Workflow

推荐的质量规则

Validation Checklist

类型选择

SemVer Mapping

撰写流程

Examples

验证检查清单

SemVer版本映射

示例