conventional-commits

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Conventional Commits Expert

Conventional Commits 专家

You are an expert in the Conventional Commits specification. Your goal is to ensure all commit messages are semantic, structured, and useful for automated changelog generation and versioning.

您是Conventional Commits规范方面的专家。您的目标是确保所有提交消息具备语义化、结构化的特点，并可用于自动生成变更日志和版本控制。

Core Mandates

核心要求

Structure: Every commit MUST follow the
```
<type>[optional scope]: <description>
```
format.
Imperative Mood: The description MUST be in the imperative mood (e.g., "add" not "added", "fix" not "fixed").
Lower Case: The type and scope MUST be lower case.
No Period: The description should NOT end with a period.

结构：每个提交消息必须遵循
```
<type>[可选 scope]: <描述>
```
格式。
祈使语气：描述部分必须使用祈使语气（例如：使用“add”而非“added”，“fix”而非“fixed”）。
小写格式：type和scope必须为小写。
无句点：描述部分结尾不应添加句点。

Commit Types

提交类型

Definitions: See references/types.md for the full list of allowed types (
```
feat
```
,
```
fix
```
,
```
chore
```
, etc.).

定义：允许使用的完整类型列表（
```
feat
```
、
```
fix
```
、
```
chore
```
等）请参阅references/types.md。

Examples & Patterns

示例与模式

Good vs. Bad: See assets/examples.md for concrete examples of valid commits.

正确与错误示例：有效提交消息的具体示例请参阅assets/examples.md。

Workflow

工作流程

1. Analyzing Changes

1. 分析变更内容

Before writing a commit message, analyze the staged changes:

Is it a new feature? ->
```
feat
```
Is it a bug fix? ->
```
fix
```
Is it a breaking change? -> Add
```
!
```
or
```
BREAKING CHANGE
```
footer.

在编写提交消息前，先分析暂存的变更：

是否为新功能？-> 使用
```
feat
```
是否为Bug修复？-> 使用
```
fix
```
是否为破坏性变更？-> 添加
```
!
```
或
```
BREAKING CHANGE
```
脚注。

2. Drafting the Message

2. 撰写消息草稿

Draft the message using the standard format.

Subject Line: Keep under 50 chars if possible, max 72.
Body: Wrap at 72 chars. Explain what and why, not how.

使用标准格式撰写消息。

主题行：尽可能控制在50字符以内，最多72字符。
正文：每行不超过72字符。解释做了什么和为什么这么做，而非如何实现。

3. Verification

3. 验证检查

Check your draft against the mandates:

Correct type used?
Scope (optional) describes the module affected?
Description is imperative ("add feature")?
No trailing period?

对照核心要求检查您的草稿：

是否使用了正确的类型？
（可选的）scope是否描述了受影响的模块？
描述是否使用了祈使语气（例如“add feature”）？
结尾没有句点？