Back to Details

gitmoji-conventional

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Gitmoji + Conventional Commits

Gitmoji + Conventional Commits

Format git commits and Pull Request titles as:
<gitmoji> <type>[optional scope][!]: <description>
Examples:
text
✨ feat(api): add OAuth login support
🔥 refactor(cache): remove deprecated cache layer
🚑 fix(auth): patch token validation vulnerability
将git提交信息和Pull Request标题格式化为：
<gitmoji> <type>[可选范围][!]: <描述>
示例：
text
✨ feat(api): add OAuth login support
🔥 refactor(cache): remove deprecated cache layer
🚑 fix(auth): patch token validation vulnerability

When to Apply

适用场景

This skill MUST be applied when the assistant:
  • generates or suggests a git commit message
  • generates or suggests a Pull Request title
  • prepares a release plan that includes a commit message
  • prepares a PR summary where a title is needed
  • responds to prompts like: "commit this", "write a commit", "create PR", "open PR", "prepare PR", "draft PR", "what should the PR title be", or similar
Apply it even if the user does not explicitly mention Conventional Commits or gitmoji.
当助手遇到以下情况时，必须应用本规范：
  • 生成或建议git提交信息
  • 生成或建议Pull Request标题
  • 制定包含提交信息的发布计划
  • 准备需要标题的PR摘要
  • 响应用户如下提示：“提交这个”、“写提交信息”、“创建PR”、“打开PR”、“准备PR”、“草拟PR”、“PR标题应该是什么”或类似表述
即使用户没有明确提到Conventional Commits或gitmoji，也需应用本规范。

Deterministic Rule

确定性规则

  1. Choose the gitmoji first
  2. Use the type mapped to that gitmoji
  3. NEVER invent new gitmoji
  4. NEVER invent new commit/PR types
Gitmoji mapping: See references/gitmoji-mapping.md for the full Gitmoji → Conventional Commit type table. Load it when choosing a gitmoji.
  1. 首先选择gitmoji
  2. 使用与该gitmoji对应的类型
  3. 绝对不要自创gitmoji
  4. 绝对不要自创提交/PR类型
Gitmoji映射关系： 完整的Gitmoji → Conventional Commit类型对照表请参见references/gitmoji-mapping.md。选择gitmoji时请参考该文档。

Choosing the Gitmoji

Gitmoji选择规则

Choose the gitmoji that best represents the main change.
If multiple changes exist, priority order: fix > feat > perf > refactor > build > docs > test > chore
For PRs with mixed changes, pick one primary semantic category. Do NOT describe all changes in the title.
选择最能代表主要变更内容的gitmoji。
若存在多项变更，优先级顺序为：fix > feat > perf > refactor > build > docs > test > chore
对于包含混合变更的PR，选择一个主要语义类别。不要在标题中描述所有变更。

Scope

范围（Scope）

Use scope when it improves clarity. Common scopes: auth, api, core, cli, ui, deps, build, ci, db.
If scope is not obvious, omit it.
当范围能提升清晰度时使用。常见范围包括：auth、api、core、cli、ui、deps、build、ci、db。
若范围不明确，则省略。

Description Rules

描述规则

The description MUST:
  • be imperative
  • be a single line
  • be concise
  • be ≤ 72 characters when possible
  • not end with a period
  • not start with list markers
Correct: 
✨ feat(api): add OAuth login support
Incorrect: 
✨ feat(api): Added OAuth login support.
or 
- ✨ feat(api): add OAuth login support
描述必须满足：
  • 使用祈使语气
  • 单行呈现
  • 简洁明了
  • 尽可能控制在72字符以内
  • 不以句号结尾
  • 不以列表标记开头
正确示例：
✨ feat(api): add OAuth login support
错误示例：
✨ feat(api): Added OAuth login support.
或 
- ✨ feat(api): add OAuth login support

Git Commits

Git提交信息

Breaking Changes

破坏性变更

If the commit introduces a breaking change, use 
<gitmoji> <type>[optional scope][!]: <description>
with a footer 
BREAKING CHANGE: <details>
.
Example:
text
💥 feat(api)!: redesign authentication API

BREAKING CHANGE: authentication endpoints changed to OAuth2
如果提交引入破坏性变更，使用格式
<gitmoji> <type>[可选范围][!]: <描述>
，并添加页脚
BREAKING CHANGE: <详情>
。
示例：
text
💥 feat(api)!: redesign authentication API

BREAKING CHANGE: authentication endpoints changed to OAuth2

Commit Body (optional)

提交正文（可选）

Use when context is helpful: 2+ meaningful changes, subject needs context, or bullet-style change notes.
  • Blank line after the subject
  • Short paragraph (optional)
  • Bullet list using "-" only
  • Keep bullets concise and action-oriented
Example:
text
✨ feat(auth): add OAuth login

- add Google provider
- add GitHub provider
- store refresh tokens securely
当需要补充上下文时使用：包含2项及以上有意义的变更、主题需要补充说明，或使用项目符号列出变更说明。
  • 主题后空一行
  • 简短段落（可选）
  • 仅使用“-”作为项目符号
  • 项目符号内容简洁且以动作导向
示例：
text
✨ feat(auth): add OAuth login

- add Google provider
- add GitHub provider
- store refresh tokens securely

Footer (optional)

页脚（可选）

Supported footers: 
BREAKING CHANGE: ...
, 
Closes #123
, 
Refs #123
支持的页脚包括：
BREAKING CHANGE: ...
、
Closes #123
、
Refs #123

Output

输出要求

  • Output ONLY the commit message
  • No explanations
  • No alternatives unless requested
  • 仅输出提交信息
  • 不添加解释说明
  • 除非用户要求，否则不提供替代方案

Pull Request Titles

Pull Request标题

Constraints

约束条件

A PR title MUST:
  • be exactly one line
  • contain no body, bullets, or footer
  • contain no issue references unless the user explicitly asks
  • be directly usable as a GitHub PR title without editing
PR标题必须：
  • 仅为单行
  • 不包含正文、项目符号或页脚
  • 除非用户明确要求，否则不包含问题引用
  • 无需编辑即可直接用作GitHub PR标题

Breaking Changes

破坏性变更

If the PR introduces a breaking change, use 
<gitmoji> <type>[optional scope][!]: <description>
. Do NOT include footers or migration notes in the title.
如果PR引入破坏性变更，使用格式
<gitmoji> <type>[可选范围][!]: <描述>
。标题中不包含页脚或迁移说明。

Output

输出要求

  • Output ONLY the PR title
  • No explanations
  • No alternatives unless requested
  • 仅输出PR标题
  • 不添加解释说明
  • 除非用户要求，否则不提供替代方案