Back to Details

git-commit

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Commit

提交

Generate commit messages. Adapt to repo style.
生成提交信息，适配仓库风格。

Format

格式

type(scope): description

[optional body]

[optional footer]
type(scope): description

[optional body]

[optional footer]

Workflow

工作流

  1. Run 
    git diff --staged
    to see changes
  2. Run 
    git log --oneline -10
    to check repo style
  3. Detect language from recent commits
  4. Detect footer patterns (Change-Id, tickets)
  5. Pick commit type from changes
  6. Infer scope from affected files
  7. Write short description
  1. 运行 
    git diff --staged
    查看变更
  2. 运行 
    git log --oneline -10
    检查仓库提交风格
  3. 从近期提交中识别使用语言
  4. 识别页脚模式（Change-Id、工单编号）
  5. 从变更内容中选择提交type
  6. 从受影响文件推断scope
  7. 编写简短描述

Language Detection

语言识别

Check recent commits:
  • Polish: Dodanie, Naprawa, Poprawa, Zmiana, Usunięcie
  • English: Add, Fix, Update, Remove, Change
Match dominant language in last 10 commits.
检查近期提交：
  • 波兰语：Dodanie, Naprawa, Poprawa, Zmiana, Usunięcie
  • 英语：Add, Fix, Update, Remove, Change
匹配最近10次提交中占主导的语言。

Atomic Commits

原子提交

One commit = one logical change.
Trigger rule: If changes need different types (feat + fix), split into separate commits.
Ask: Can this be described in one subject line without "and"?
Bad:
feat(ios): Add mTLS support and fix cache tests
Good (split into two):
feat(ios): Add mTLS certificate injection
fix(ios): Fix cache tests for lowercase headers
一次提交 = 一项逻辑变更。
触发规则： 如果变更需要不同的type（feat + fix），拆分为独立提交。
判断标准：能否不使用"and"就用一行主题描述本次变更？
错误示例：
feat(ios): Add mTLS support and fix cache tests
正确示例（拆分为两个提交）：
feat(ios): Add mTLS certificate injection
fix(ios): Fix cache tests for lowercase headers

Style Rules

风格规则

  • Imperative mood: "add" not "added"
  • No period at end
  • No em dashes in prose
  • Under 50 chars for subject
  • Match repo language and conventions
Em dash vs hyphen:
  • Bad: "add auth - with token support"
  • Good: "add auth with token support"
  • 祈使语气：用"add"而非"added"
  • 结尾不加句号
  • 正文中不使用长破折号
  • 主题长度不超过50个字符
  • 匹配仓库语言和规范
长破折号 vs 连字符：
  • 错误："add auth - with token support"
  • 正确："add auth with token support"

Writing Style

写作风格

Be laconic:
  • Shortest possible subject
  • No filler words
  • No bullet points in body
  • No verbose explanations
  • Skip body unless essential
Body is noise unless it adds value.
Subject examples:
  • Bad: "Add Error convenience extensions for NetworkError"
  • Good: "Add Error NetworkError extensions"
Body examples:
Bad (bullets):
feat(ios): Add mTLS support

- Add certificate fields
- Extract PEM data
Good (subject only):
feat(ios): Add mTLS certificate injection
Good (prose body when needed):
refactor(auth): Extract token service

Separate token logic for unit testing.
尽量简洁：
  • 主题尽可能简短
  • 不加填充词
  • 正文中不使用项目符号
  • 不使用冗长解释
  • 除非必要，省略正文
正文如果不能提供额外价值就是冗余信息。
主题示例：
  • 错误："Add Error convenience extensions for NetworkError"
  • 正确："Add Error NetworkError extensions"
正文示例：
错误（带项目符号）：
feat(ios): Add mTLS support

- Add certificate fields
- Extract PEM data
正确（仅主题）：
feat(ios): Add mTLS certificate injection
正确（需要时添加正文）：
refactor(auth): Extract token service

Separate token logic for unit testing.

Body

正文

Prefer no body. A good subject makes body unnecessary.
Decision tree:
  1. Subject self-explanatory? Skip body
  2. Multiple unrelated changes? Split commits
  3. Need to explain "why"? Add prose body (1-2 sentences)
If body needed:
  • Prose only, no bullets
  • Explain why, not what
  • One sentence per logical change
  • Keep short
优先不使用正文。 优秀的主题不需要额外正文说明。
决策树：
  1. 主题是否自解释？跳过正文
  2. 存在多个不相关变更？拆分提交
  3. 需要解释变更原因？添加正文（1-2句话）
如果需要正文：
  • 仅使用普通文本，不要项目符号
  • 解释原因，而非变更内容
  • 每一项逻辑变更对应一句话
  • 保持简短

Breaking Changes

破坏性变更

Add exclamation mark after type or scope:
feat!: remove deprecated API
feat(api)!: change response format
Or use footer:
feat: update auth flow

BREAKING CHANGE: token format changed
在type或scope后添加感叹号：
feat!: remove deprecated API
feat(api)!: change response format
或者使用页脚：
feat: update auth flow

BREAKING CHANGE: token format changed

Footers

页脚

Detect from repo history:
  • Change-Id (Gerrit): preserve if present
  • Ticket IDs (JIRA): include if pattern found
  • Signed-off-by: include if repo uses it
Do not add footers the repo does not use.
从仓库历史中识别：
  • Change-Id（Gerrit）：如果存在则保留
  • 工单编号（JIRA）：如果匹配到对应格式则包含
  • Signed-off-by：如果仓库使用该规范则包含
不要添加仓库未使用的页脚内容。

Safety

安全注意

  • Check 
    git status
    first
  • Never commit secrets
  • Verify staged files before commit
See 
quick-reference.md
for type details.
  • 先检查 
    git status
  • 永远不要提交私密信息
  • 提交前验证暂存文件
提交type详情可查看
quick-reference.md
。