conventional-commit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Conventional Commit

Use this skill to produce concise, accurate Conventional Commit messages. Derive the message from the actual diff, issue, or user-provided summary. Use Chinese as the default language for descriptions, bodies, and change impact. If the change mixes unrelated work, recommend separate commits before drafting one broad message.

使用本技能生成简洁、准确的Conventional Commit提交信息。根据实际代码差异、问题工单或用户提供的摘要生成信息。描述、正文和变更影响默认使用中文。如果变更包含不相关的工作内容，建议先拆分为独立提交，再草拟宽泛的提交信息。

Core Format

核心格式

text

type(scope): description
type: description
type(scope)!: description

Rules:

```
type
```
and
```
description
```
are required.
```
scope
```
is optional; use it only when it clarifies the changed area.
```
!
```
marks a breaking change and must not be used for ordinary changes.
Keep syntax tokens such as
```
type
```
,
```
scope
```
,
```
BREAKING CHANGE
```
,
```
Closes
```
,
```
Fixes
```
, and
```
Refs
```
in their standard form.
Write the description primarily in Chinese; keep it concise, specific, action-oriented, and free of a trailing period.
Prefer one logical change per commit.

text

type(scope): description
type: description
type(scope)!: description

规则：

```
type
```
和
```
description
```
为必填项。
```
scope
```
为可选项；仅当它能明确变更区域时才使用。
```
!
```
用于标记破坏性变更，普通变更不得使用。
语法标记如
```
type
```
、
```
scope
```
、
```
BREAKING CHANGE
```
、
```
Closes
```
、
```
Fixes
```
和
```
Refs
```
需保持标准形式。
描述主要使用中文；需简洁、具体、以行为导向，且末尾不加句号。
优先为每个提交包含一个逻辑变更。

Type Reference

类型参考

Use repository-specific types when they exist. Otherwise use this common set:

Type	When to use	Example
`feat`	User-facing feature or capability	`feat(auth): 添加 OAuth2 登录`
`fix`	Bug fix	`fix(api): 处理空用户响应`
`refactor`	Code change without behavior change	`refactor(db): 抽取查询构建器`
`perf`	Performance improvement	`perf(search): 添加邮箱查询索引`
`docs`	Documentation only	`docs: 更新 API 示例`
`test`	Tests only	`test(auth): 覆盖令牌刷新`
`style`	Formatting only	`style: 格式化源文件`
`build`	Build system or dependency packaging	`build: 切换到 hatch`
`ci`	CI configuration or automation	`ci: 添加 Python 3.12 任务`
`chore`	Maintenance that does not fit other types	`chore: 更新锁文件`
`revert`	Revert a prior commit	`revert: revert "feat(auth): 添加 OAuth2 登录"`

若仓库有特定类型则优先使用，否则使用以下通用类型：

类型	使用场景	示例
`feat`	用户可见的功能或能力	`feat(auth): 添加 OAuth2 登录`
`fix`	Bug修复	`fix(api): 处理空用户响应`
`refactor`	不改变行为的代码变更	`refactor(db): 抽取查询构建器`
`perf`	性能优化	`perf(search): 添加邮箱查询索引`
`docs`	仅文档变更	`docs: 更新 API 示例`
`test`	仅测试代码变更	`test(auth): 覆盖令牌刷新`
`style`	仅代码格式调整	`style: 格式化源文件`
`build`	构建系统或依赖打包变更	`build: 切换到 hatch`
`ci`	CI配置或自动化流程变更	`ci: 添加 Python 3.12 任务`
`chore`	其他类型不涵盖的维护工作	`chore: 更新锁文件`
`revert`	回滚之前的提交	`revert: revert "feat(auth): 添加 OAuth2 登录"`

Body and Footers

正文与页脚

Add a body when the header does not explain the rationale, impact, or main implementation details. Separate the header, body, and footers with blank lines.

text

feat(auth): 添加 JWT 认证

- 添加登录和注册接口
- 使用 argon2 存储密码哈希
- 通过中间件保护认证路由

Closes #42

Footer guidance:

Use
```
Closes #42
```
or
```
Fixes #42
```
when merging should close the issue.
Use
```
Refs #42
```
when the commit only relates to the issue.
Use
```
Co-authored-by: Name <email>
```
for co-authored work.

当标题无法解释变更理由、影响或主要实现细节时，添加正文。标题、正文和页脚之间用空行分隔。

text

feat(auth): 添加 JWT 认证

- 添加登录和注册接口
- 使用 argon2 存储密码哈希
- 通过中间件保护认证路由

Closes #42

页脚指南：

当合并提交应关闭问题时，使用
```
Closes #42
```
或
```
Fixes #42
```
。
当提交仅与问题相关时，使用
```
Refs #42
```
。
对于合作完成的工作，使用
```
Co-authored-by: Name <email>
```
。

Breaking Changes

破坏性变更

Mark breaking changes only when consumers must change usage, configuration, or integration code.

Use

in the header for visibility. Add a

BREAKING CHANGE:

footer when migration context is useful.

text

feat(api)!: 要求使用 bearer token

BREAKING CHANGE: API 客户端必须发送 Authorization: Bearer 请求头，
不再支持原有的 X-API-Key 请求头。

仅当使用者必须更改用法、配置或集成代码时，才标记破坏性变更。在标题中使用

以提高可见性。当需要迁移上下文信息时，添加

BREAKING CHANGE:

页脚。

text

feat(api)!: 要求使用 bearer token

BREAKING CHANGE: API 客户端必须发送 Authorization: Bearer 请求头，
不再支持原有的 X-API-Key 请求头。

Drafting Workflow

草拟流程

Inspect the diff, issue, or user-provided change summary.
Choose the narrowest accurate type.
Add a scope only if it improves clarity.
Write a short Chinese description unless the repository or user requires another language.
Add a body for non-obvious rationale or impact.
Add breaking-change and issue footers when required.

检查代码差异、问题工单或用户提供的变更摘要。
选择最精准的类型。
仅当能提升清晰度时才添加范围。
撰写简短的中文描述，除非仓库或用户要求使用其他语言。
对于非显而易见的理由或影响，添加正文。
必要时添加破坏性变更和问题页脚。

Verification Checklist

验证清单

Header follows

type(scope): description

type: description

, or

type(scope)!: description

Commit type matches the actual nature of the change
Scope is short and meaningful, or omitted
Description uses Chinese as the primary language unless overridden
Body explains non-obvious context in Chinese when needed
Breaking change marker is present only when required
Issue footer closes or references issues intentionally

标题遵循

type(scope): description

、

type: description

或

type(scope)!: description

格式

提交类型与变更的实际性质匹配
范围简短且有意义，或已省略
描述主要使用中文（除非被覆盖）
必要时，正文用中文解释非显而易见的上下文
仅在必要时存在破坏性变更标记
问题页脚有意关闭或引用问题