commit
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseCommit Skill
Commit 技能
Creates well-formatted commits following conventional commit standards.
按照约定式提交（conventional commits）标准创建格式规范的提交。
Core Features
核心功能
- Staged vs unstaged detection - commits only staged files when present
- Split suggestions - analyzes diffs for multiple logical changes
- Conventional commits format:
<type>: <description> - Pre-commit hook integration
- Always for DCO compliance
--signoff
- 暂存与未暂存文件检测 - 当存在暂存文件时，仅提交暂存文件
- 拆分建议 - 分析差异以识别多个逻辑变更
- 约定式提交格式：
<type>: <description> - 提交前钩子集成
- 始终添加以符合DCO合规要求
--signoff
Process
流程
1. Analyze Changes
1. 分析变更
bash
git status --shortbash
git status --shortPrefer staged files if any exist
Prefer staged files if any exist
if ! git diff --staged --quiet; then
git diff --staged --stat
else
git diff HEAD --stat
fi
undefinedif ! git diff --staged --quiet; then
git diff --staged --stat
else
git diff HEAD --stat
fi
undefined2. Multi-Concern Detection
2. 多关注点检测
Suggest split if:
- Different patterns: +
src/+test/docs/ - Mixed types: feat + fix + docs
- Unrelated concerns: auth logic + UI styling
- Large changeset: >500 lines
Ask user:
Multiple concerns detected:
1. Auth changes (src/auth/*)
2. UI updates (src/components/*)
3. Docs (README.md)
Split into 3 commits?
- feat: add JWT authentication
- style: update login UI
- docs: update auth documentation
[split/all]当出现以下情况时建议拆分：
- 不同目录模式：+
src/+test/docs/ - 混合类型：feat + fix + docs
- 不相关关注点：认证逻辑 + UI样式
- 大型变更集：超过500行
询问用户：
检测到多个关注点：
1. 认证变更 (src/auth/*)
2. UI更新 (src/components/*)
3. 文档 (README.md)
拆分为3个提交？
- feat: add JWT authentication
- style: update login UI
- docs: update auth documentation
[split/all]3. Create Commit
3. 创建提交
Format:
<type>: <description>Rules:
- Imperative mood ("add" not "added")
- First line <72 chars
- Atomic (single purpose)
- Use body for "why" if needed
bash
git commit --signoff -m "<type>: <description>"格式：
<type>: <description>规则：
- 使用祈使语气（用“add”而非“added”）
- 首行不超过72字符
- 原子性（单一目的）
- 如有需要，在提交正文中说明“原因”
bash
git commit --signoff -m "<type>: <description>"Commit Body Conventions
提交正文约定
When changes need more context, add a body:
bash
git commit --signoff -m "$(cat <<'EOF'
<type>: <description>
<body>
EOF
)"当变更需要更多上下文时，添加提交正文：
bash
git commit --signoff -m "$(cat <<'EOF'
<type>: <description>
<body>
EOF
)"When to Include Body
何时包含提交正文
- Multiple files changed
- Non-obvious reasoning
- Breaking changes
- Related issues/PRs
- 多个文件变更
- 变更原因不明显
- 破坏性变更
- 关联问题/PR
Body Format
提交正文格式
- Blank line after subject
- Wrap at 72 chars
- Explain "why" not "what"
- Use bullet points for lists
- 主题行后空一行
- 每行不超过72字符
- 解释“原因”而非“内容”
- 列表使用项目符号
Body Example
提交正文示例
feat: add user authentication
- Implement JWT token validation
- Add protected routes middleware
- Include refresh token support
Closes #123feat: add user authentication
- Implement JWT token validation
- Add protected routes middleware
- Include refresh token support
Closes #123Breaking Changes
破坏性变更
Add exclamation mark (!) after type for breaking changes:
feat!: change API response format
BREAKING CHANGE: Response now returns { data, meta }
instead of flat object. Update all API consumers.在类型后添加感叹号(!)表示破坏性变更：
feat!: change API response format
BREAKING CHANGE: Response now returns { data, meta }
instead of flat object. Update all API consumers.4. Handle --no-verify
4. 处理--no-verify
If user requests :
--no-verifyWarning: Requested to skip pre-commit hooks.
Bypasses: linting, tests, formatting
Reason: [ask user]
Approve? [yes/no]Only proceed if confirmed.
如果用户请求：
--no-verify警告：请求跳过提交前钩子。
将绕过：代码检查、测试、格式化
原因：[询问用户]
是否批准？[yes/no]仅在确认后继续执行。
Commit Types
提交类型
| Type | Use Case |
|---|---|
| feat | New feature |
| fix | Bug fix |
| docs | Documentation |
| style | Formatting, styling |
| refactor | Code restructure |
| perf | Performance |
| test | Tests |
| chore | Build/tools |
| ci | CI/CD |
| security | Security fix |
| build | Build system |
| revert | Revert changes |
| wip | Work in progress |
| 类型 | 使用场景 |
|---|---|
| feat | 新功能 |
| fix | 修复Bug |
| docs | 文档更新 |
| style | 格式调整、样式修改 |
| refactor | 代码重构 |
| perf | 性能优化 |
| test | 测试相关 |
| chore | 构建/工具维护 |
| ci | CI/CD配置 |
| security | 安全修复 |
| build | 构建系统调整 |
| revert | 回滚变更 |
| wip | 进行中的工作 |
Split Examples
拆分示例
Bad - Mixed concerns
错误示例 - 混合关注点
diff
+ src/auth/login.ts (feat)
+ src/components/Button.css (style)
+ README.md (docs)Split into: 3 separate commits
diff
+ src/auth/login.ts (feat)
+ src/components/Button.css (style)
+ README.md (docs)拆分为：3个独立提交
Good - Single concern
正确示例 - 单一关注点
diff
+ src/auth/login.ts
+ src/auth/middleware.ts
+ tests/auth.test.tsOne commit:
feat: add authenticationdiff
+ src/auth/login.ts
+ src/auth/middleware.ts
+ tests/auth.test.ts一个提交：
feat: add authenticationCritical Rules
关键规则
NEVER
绝对禁止
- Add Claude signature to commits
- Commit without checking staged status
- Skip split suggestions for multi-concern
- Use past tense ("added" -> "add")
- Make first line >72 chars
- Bypass hooks without asking
- 向提交中添加Claude签名
- 未检查暂存状态就提交
- 对多关注点变更跳过拆分建议
- 使用过去式（“added”改为“add”）
- 首行超过72字符
- 未询问就绕过钩子
ALWAYS
必须遵守
- Use --signoff flag
- Analyze diff before commit
- Suggest splits when appropriate
- Use imperative mood
- Pick correct type
- Ask approval for --no-verify
- 使用--signoff标志
- 提交前分析差异
- 适当情况下建议拆分
- 使用祈使语气
- 选择正确的提交类型
- 询问是否批准使用--no-verify