git-commit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Git Commit

Git提交

Write clean, atomic commits that communicate intent clearly.

撰写清晰传达意图的、原子化的Git提交。

When to Use This Skill

何时使用此技能

Activate when any of the following are true:

User asks to "commit", "make a commit", "stage changes", or "write a commit message"
User says "commit my changes" or "commit this"
A logical unit of work is complete and ready to land
User asks about
```
git add
```
,
```
git commit
```
, or
```
git amend
```

当出现以下任一情况时激活：

用户要求“commit”、“make a commit”、“stage changes”或“write a commit message”
用户说“commit my changes”或“commit this”
一个逻辑工作单元已完成并准备提交
用户询问
```
git add
```
、
```
git commit
```
或
```
git amend
```
相关内容

Decision Tree

决策树

What does the user need?

Stage + commit changes?
  → Check what changed: git status + git diff --staged
  → Group related changes (atomic commit rule below)
  → Write message in conventional format
  → If hook fails: fix root cause, re-stage, new commit

Amend the last commit?
  → ONLY if NOT yet pushed to remote
  → OK for: missing file, minor message fix, small oversight
  → New commit instead: substantial change, already pushed

Write a commit message only?
  → Follow conventional format below
  → Lead with "why", not "what"

Hook failure?
  → Read the full hook output
  → Fix the root cause — never use --no-verify

用户需要什么？

暂存并提交变更？
  → 检查变更内容：git status + git diff --staged
  → 分组相关变更（遵循下方原子化提交规则）
  → 按照规范格式撰写提交信息
  → 如果钩子失败：修复根本原因，重新暂存，新建提交

修改上次提交？
  → 仅适用于**尚未推送到远程仓库**的情况
  → 适用场景：遗漏文件、提交信息小修改、小疏忽
  → 应新建提交的情况：重大变更、已推送到远程

仅撰写提交信息？
  → 遵循下方的规范格式
  → 以“为什么”而非“做了什么”开头

钩子失败？
  → 阅读完整的钩子输出
  → 修复根本原因 — 切勿使用 --no-verify

Conventional Commits Format

Conventional Commits 格式

<type>(<scope>): <subject>

<body>      ← optional; explain *why*, not *what*
<footer>    ← optional; breaking changes, refs

<type>(<scope>): <subject>

<body>      ← 可选；解释*为什么*，而非*做了什么*
<footer>    ← 可选；破坏性变更、引用关联

Types

类型

Type	When
`feat`	New feature or capability
`fix`	Bug fix
`refactor`	Code restructure, no behavior change
`docs`	Documentation only
`test`	Adding or fixing tests
`chore`	Build, tooling, dependency updates
`perf`	Performance improvement
`ci`	CI/CD workflow changes

Type	适用场景
`feat`	新增功能或能力
`fix`	修复Bug
`refactor`	代码重构，无行为变更
`docs`	仅修改文档
`test`	添加或修复测试
`chore`	构建、工具链、依赖更新
`perf`	性能优化
`ci`	CI/CD 工作流变更

Rules

规则

Subject: ≤ 72 chars, imperative mood ("add" not "added"), no trailing period
Body: wrap at 72 chars; explain motivation, not mechanics
Breaking change:
```
BREAKING CHANGE:
```
footer, or
```
!
```
after type (
```
feat!:
```
)

主题（Subject）：≤72字符，使用祈使语气（用“add”而非“added”），末尾无句号
正文（Body）：每行不超过72字符；解释动机而非实现细节
破坏性变更：在页脚标注
```
BREAKING CHANGE:
```
，或在类型后加
```
!
```
（如
```
feat!:
```
）

Atomic Commits

原子化提交

One commit = one logical change. A reviewer should understand it without other commits.

Group together: all files for a single feature or fix; tests with the code they cover.

Keep separate: refactors from behavior changes; unrelated fixes; half-done work.

Never commit "WIP" or "misc fixes" — squash or split before finalizing.

一次提交 = 一个逻辑变更。评审者无需查看其他提交即可理解本次变更。

**应归为一组：**单个功能或修复涉及的所有文件；与代码对应的测试用例。

**应分开提交：**重构与行为变更；不相关的修复；未完成的工作。

切勿提交“WIP”（进行中）或“misc fixes”（杂项修复）类的提交 — 最终提交前需合并或拆分。

Staging Checklist

暂存检查清单

Before

git add

, verify:

No secrets, API keys, or credentials
No debug code or temporary hacks (
```
console.log
```
,
```
TODO: remove
```
)
Changes are related (one logical unit)
```
.gitignore
```
respected — no build artifacts or generated files unless intentional

执行

git add

前，请确认：

无密钥、API密钥或凭证信息
无调试代码或临时 hack（如
```
console.log
```
、
```
TODO: remove
```
）
变更内容相关（属于一个逻辑单元）
遵守
```
.gitignore
```
规则 — 除非有意提交，否则不要包含构建产物或生成文件

Examples

示例

Feature

功能新增

feat(auth): add OAuth2 login flow

Replaces username/password form. Supports Google and GitHub as providers.
Token refresh is handled automatically by the auth middleware.

feat(auth): add OAuth2 login flow

Replaces username/password form. Supports Google and GitHub as providers.
Token refresh is handled automatically by the auth middleware.

Bug fix

Bug修复

fix(publish): handle missing platform binary gracefully

Previously threw unhandled error when the platform package was absent.
Now logs a clear message and exits with code 1.

fix(publish): handle missing platform binary gracefully

Previously threw unhandled error when the platform package was absent.
Now logs a clear message and exits with code 1.

Breaking change

破坏性变更

feat!: change publish config to support multiple binaries

BREAKING CHANGE: `binary` field renamed to `binaries` array.
Migrate: `binary: 'my-cli'` → `binaries: [{ name: 'my-cli', ... }]`

feat!: change publish config to support multiple binaries

BREAKING CHANGE: `binary` field renamed to `binaries` array.
Migrate: `binary: 'my-cli'` → `binaries: [{ name: 'my-cli', ... }]`

Chore

杂项任务

chore(deps): upgrade pnpm to 10.6.2

chore(deps): upgrade pnpm to 10.6.2

Pre-commit Hook Failures

提交前钩子失败处理

Read the full hook output — it tells you exactly what failed
Fix the underlying issue (lint, type error, formatting)
Re-stage the fixed files
Create a new commit — do not amend the failed attempt
Never use
```
--no-verify
```
unless the user explicitly asks

阅读完整的钩子输出 — 它会明确告知失败原因
修复根本问题（ lint 错误、类型错误、格式问题）
重新暂存修复后的文件
创建新的提交 — 不要修改失败的提交
除非用户明确要求，否则切勿使用
```
--no-verify
```

Setup & Activation

设置与激活

bash

npx skills add -g onsager-ai/dev-skills --skill git-commit -a claude-code -y

Auto-activates when: user says "commit", "stage", "git add", or "commit message".

bash

npx skills add -g onsager-ai/dev-skills --skill git-commit -a claude-code -y

自动触发场景：用户提及“commit”、“stage”、“git add”或“commit message”时。