git-commit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Conventional Commits

Default commit format: Conventional Commits. Use this format for all commits and PR/MR titles unless the project defines its own commit conventions (in CLAUDE.md, AGENTS.md, contributing guides, or similar). Project-specific rules always take priority.

默认提交格式：Conventional Commits。除非项目在CLAUDE.md、AGENTS.md、贡献指南或类似文档中定义了自己的提交规范，否则所有提交和PR/MR标题都应遵循此格式。项目特定规则始终优先。

When to Use

适用场景

Making any git commit -- this skill defines the required format
Creating PR/MR titles -- squash merges use the title as the commit message
Writing squash merge messages -- must follow the same format
Reviewing commit message format -- validate against these rules

进行任何Git提交——本技能定义了必填格式
创建PR/MR标题——合并提交会将标题用作提交消息
编写合并提交消息——必须遵循相同格式
审核提交消息格式——根据这些规则验证

Critical Rules

核心规则

Project rules override this skill -- if the project defines commit message conventions (issue number prefixes, custom formats, etc.), follow those instead. This skill is the default when no project-specific rules exist.
Type is required -- never commit without a type prefix
Description is lowercase, imperative mood, no period:
```
fix: handle null response
```
not
```
Fix: Handled null response.
```
No
Co-Authored-By
trailer -- never add it to commit messages
Describe the change, not the process -- never write review provenance (
```
fix: coderabbit round 2 fixes
```
,
```
fix: address review feedback
```
) as the message; state what the commit changes. The trigger for the change already lives in the PR and its threads.
No filler -- the description alone is usually the whole message; add a body only for information the description and diff cannot carry (breaking change details, migration steps, non-obvious constraints). Never narrate the diff.

项目规则优先于本技能——如果项目定义了提交消息规范（如 issue 编号前缀、自定义格式等），则遵循项目规则。当没有项目特定规则时，本技能作为默认规范。
必须包含类型前缀——提交时绝不能省略类型前缀
描述部分使用小写、祈使语气，无句号：例如
```
fix: handle null response
```
，而非
```
Fix: Handled null response.
```
禁止添加
Co-Authored-By
尾部信息——绝不要在提交消息中添加该内容
描述变更内容，而非流程——不要将评审来源（如
```
fix: coderabbit round 2 fixes
```
、
```
fix: address review feedback
```
）写入消息；应说明提交变更了什么。变更的触发原因已记录在PR及其讨论线程中。
无冗余内容——通常仅描述部分即可构成完整消息；仅当描述和代码差异无法传达信息时（如破坏性变更细节、迁移步骤、非显性约束）才添加正文。绝不要复述代码差异。

Provider Detection

供应商检测

Detect the git provider to use the correct CLI:

bash

git remote get-url origin

Remote URL contains	Provider	CLI	PR term
`github.com`	GitHub	`gh`	PR
`gitlab.com` or self-hosted GitLab	GitLab	`glab`	MR

If ambiguous or both present, ask the user.

检测Git供应商以使用正确的CLI：

bash

git remote get-url origin

远程URL包含内容	供应商	CLI	PR术语
`github.com`	GitHub	`gh`	PR
`gitlab.com` 或自托管GitLab	GitLab	`glab`	MR

如果存在歧义或同时包含两者，请询问用户。

Format

格式

text

<type>(<optional scope>): <description>

[optional body]

[optional footer(s)]

text

<type>(<可选范围>): <描述>

[可选正文]

[可选尾部信息]

Types

类型说明

Type	When
`feat`	New feature or capability
`fix`	Bug fix
`docs`	Documentation only
`style`	Formatting, whitespace, semicolons (no logic change)
`refactor`	Code change that neither fixes a bug nor adds a feature
`perf`	Performance improvement
`test`	Adding or updating tests
`build`	Build system or external dependencies
`ci`	CI/CD configuration
`chore`	Maintenance tasks, tooling, config

类型	适用场景
`feat`	新增功能或能力
`fix`	修复Bug
`docs`	仅修改文档
`style`	格式调整、空白字符、分号修改（无逻辑变更）
`refactor`	既不修复Bug也不新增功能的代码变更
`perf`	性能优化
`test`	添加或更新测试
`build`	构建系统或外部依赖变更
`ci`	CI/CD配置变更
`chore`	维护任务、工具或配置调整

Rules

规则细则

Type is required -- never commit without a type prefix
Scope is optional but encouraged for multi-module repos:
```
feat(auth): add OAuth2 flow
```
Description is lowercase, imperative mood, no period:
```
fix: handle null response
```
not
```
Fix: Handled null response.
```
Breaking changes use
```
!
```
after type/scope:
```
feat(api)!: remove v1 endpoints
```
PR/MR titles follow the same format -- squash merges use the PR/MR title as the commit message
No
Co-Authored-By
trailer -- never add it to commit messages
Describe the change, not the process -- state what changed, never why a reviewer asked for it (see Review-Fix Commits below)
Body is optional and rare -- add one only for what the description and diff cannot carry; never restate the diff or pad with narrative

必须包含类型前缀——提交时绝不能省略类型前缀
范围为可选内容，但在多模块仓库中建议添加：例如
```
feat(auth): add OAuth2 flow
```
描述部分使用小写、祈使语气，无句号：例如
```
fix: handle null response
```
，而非
```
Fix: Handled null response.
```
破坏性变更需在类型/范围后添加
```
!
```
：例如
```
feat(api)!: remove v1 endpoints
```
PR/MR标题遵循相同格式——合并提交会将PR/MR标题用作提交消息
禁止添加
Co-Authored-By
尾部信息——绝不要在提交消息中添加该内容
描述变更内容，而非流程——说明变更了什么，不要提及评审者要求变更的原因（详见下方评审修复提交说明）
正文为可选内容且极少使用——仅当描述和代码差异无法传达信息时才添加；绝不要复述代码差异或添加冗余叙述

Commit Examples

提交示例

bash

git commit -m "feat: add user profile page"
git commit -m "fix(auth): prevent token refresh race condition"
git commit -m "docs: update API reference for v2 endpoints"
git commit -m "refactor(db): extract connection pooling logic"
git commit -m "feat(api)!: change response format for /users"

bash

git commit -m "feat: add user profile page"
git commit -m "fix(auth): prevent token refresh race condition"
git commit -m "docs: update API reference for v2 endpoints"
git commit -m "refactor(db): extract connection pooling logic"
git commit -m "feat(api)!: change response format for /users"

Review-Fix Commits

评审修复提交

Commits that address review feedback (human or bot) follow the same rule as any other commit: the message states what changed. The trigger -- reviewer, bot, round number -- is process context that already lives in the PR threads and is noise in

git log

Noise (never) Signal

Noise (never)	Signal
`fix: coderabbit round 2 fixes`	`fix: guard nil user in session refresh`
`fix: address PR review feedback`	`fix: close file handle on early return`
`chore: apply copilot suggestions`	`refactor: dedupe retry logic across fetchers`

fix: coderabbit round 2 fixes

fix: guard nil user in session refresh

fix: address PR review feedback

fix: close file handle on early return

chore: apply copilot suggestions

refactor: dedupe retry logic across fetchers

One review round can produce commits of different types -- split by change, not by round.

针对评审反馈（人工或机器人）的提交需遵循与其他提交相同的规则：消息需说明变更内容。触发原因——评审者、机器人、评审轮次——属于流程上下文，已记录在PR讨论线程中，写入

git log

会造成冗余。

冗余内容（禁止使用）有效内容（推荐使用）

冗余内容（禁止使用）	有效内容（推荐使用）
`fix: coderabbit round 2 fixes`	`fix: guard nil user in session refresh`
`fix: address PR review feedback`	`fix: close file handle on early return`
`chore: apply copilot suggestions`	`refactor: dedupe retry logic across fetchers`

fix: coderabbit round 2 fixes

fix: guard nil user in session refresh

fix: address PR review feedback

fix: close file handle on early return

chore: apply copilot suggestions

refactor: dedupe retry logic across fetchers

一轮评审可能产生不同类型的提交——应按变更类型拆分，而非按评审轮次拆分。

PR/MR Title Examples

PR/MR标题示例

Provider	Create PR/MR with title
GitHub	`gh pr create --title "feat: add dark mode" --body "..."`
GitLab	`glab mr create --title "feat: add dark mode" --description "..."`

供应商	创建PR/MR时设置标题的命令
GitHub	`gh pr create --title "feat: add dark mode" --body "..."`
GitLab	`glab mr create --title "feat: add dark mode" --description "..."`