commit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Claude Command: Commit

Claude 命令：Commit

Your job is to create well-formatted commits with conventional commit messages and emoji.

你的任务是使用规范化提交信息和表情符号创建格式规范的Git提交。

Instructions

操作说明

CRITICAL: Perform the following steps exactly as described:

Branch check: Checks if current branch is
```
master
```
or
```
main
```
. If so, asks the user whether to create a separate branch before committing. If user confirms a new branch is needed, creates one using the pattern
```
<type>/<username>/<description>
```
(e.g.,
```
feature/leovs09/add-new-command
```
)
Unless specified with
```
--no-verify
```
, automatically runs pre-commit checks like
```
pnpm lint
```
or simular depending on the project language.
Checks which files are staged with
```
git status
```
If 0 files are staged, automatically adds all modified and new files with
```
git add
```
Performs a
```
git diff
```
to understand what changes are being committed
Analyzes the diff to determine if multiple distinct logical changes are present
If multiple distinct changes are detected, suggests breaking the commit into multiple smaller commits
For each commit (or the single commit if not split), creates a commit message using emoji conventional commit format

重要提示：严格按照以下步骤执行：

分支检查：检查当前分支是否为
```
master
```
或
```
main
```
。如果是，则询问用户是否要在提交前创建单独分支。若用户确认需要新分支，则按照
```
<type>/<username>/<description>
```
的格式创建分支（例如：
```
feature/leovs09/add-new-command
```
）
除非使用
```
--no-verify
```
参数指定，否则会自动运行预提交检查，如
```
pnpm lint
```
或其他与项目语言对应的检查命令。
通过
```
git status
```
检查已暂存的文件
如果没有文件被暂存，则自动使用
```
git add
```
添加所有修改和新增的文件
执行
```
git diff
```
以了解提交的具体变更内容
分析diff结果，判断是否存在多个独立的逻辑变更
如果检测到多个独立变更，建议将提交拆分为多个更小的提交
对于每个提交（若未拆分则为单个提交），使用带表情符号的规范化提交格式创建提交信息

Best Practices for Commits

提交最佳实践

Verify before committing: Ensure code is linted, builds correctly, and documentation is updated
Atomic commits: Each commit should contain related changes that serve a single purpose
Split large changes: If changes touch multiple concerns, split them into separate commits
Conventional commit format: Use the format
```
<type>: <description>
```
where type is one of:
- ```
feat
```
  : A new feature
- ```
fix
```
  : A bug fix
- ```
docs
```
  : Documentation changes
- ```
style
```
  : Code style changes (formatting, etc)
- ```
refactor
```
  : Code changes that neither fix bugs nor add features
- ```
perf
```
  : Performance improvements
- ```
test
```
  : Adding or fixing tests
- ```
chore
```
  : Changes to the build process, tools, etc.
Present tense, imperative mood: Write commit messages as commands (e.g., "add feature" not "added feature")
Concise first line: Keep the first line under 72 characters
Emoji: Each commit type is paired with an appropriate emoji:
- ✨
```
feat
```
  : New feature
- 🐛
```
fix
```
  : Bug fix
- 📝
```
docs
```
  : Documentation
- 💄
```
style
```
  : Formatting/style
- ♻️
```
refactor
```
  : Code refactoring
- ⚡️
```
perf
```
  : Performance improvements
- ✅
```
test
```
  : Tests
- 🔧
```
chore
```
  : Tooling, configuration
- 🚀
```
ci
```
  : CI/CD improvements
- 🗑️
```
revert
```
  : Reverting changes
- 🧪
```
test
```
  : Add a failing test
- 🚨
```
fix
```
  : Fix compiler/linter warnings
- 🔒️
```
fix
```
  : Fix security issues
- 👥
```
chore
```
  : Add or update contributors
- 🚚
```
refactor
```
  : Move or rename resources
- 🏗️
```
refactor
```
  : Make architectural changes
- 🔀
```
chore
```
  : Merge branches
- 📦️
```
chore
```
  : Add or update compiled files or packages
- ➕
```
chore
```
  : Add a dependency
- ➖
```
chore
```
  : Remove a dependency
- 🌱
```
chore
```
  : Add or update seed files
- 🧑‍💻
```
chore
```
  : Improve developer experience
- 🧵
```
feat
```
  : Add or update code related to multithreading or concurrency
- 🔍️
```
feat
```
  : Improve SEO
- 🏷️
```
feat
```
  : Add or update types
- 💬
```
feat
```
  : Add or update text and literals
- 🌐
```
feat
```
  : Internationalization and localization
- 👔
```
feat
```
  : Add or update business logic
- 📱
```
feat
```
  : Work on responsive design
- 🚸
```
feat
```
  : Improve user experience / usability
- 🩹
```
fix
```
  : Simple fix for a non-critical issue
- 🥅
```
fix
```
  : Catch errors
- 👽️
```
fix
```
  : Update code due to external API changes
- 🔥
```
fix
```
  : Remove code or files
- 🎨
```
style
```
  : Improve structure/format of the code
- 🚑️
```
fix
```
  : Critical hotfix
- 🎉
```
chore
```
  : Begin a project
- 🔖
```
chore
```
  : Release/Version tags
- 🚧
```
wip
```
  : Work in progress
- 💚
```
fix
```
  : Fix CI build
- 📌
```
chore
```
  : Pin dependencies to specific versions
- 👷
```
ci
```
  : Add or update CI build system
- 📈
```
feat
```
  : Add or update analytics or tracking code
- ✏️
```
fix
```
  : Fix typos
- ⏪️
```
revert
```
  : Revert changes
- 📄
```
chore
```
  : Add or update license
- 💥
```
feat
```
  : Introduce breaking changes
- 🍱
```
assets
```
  : Add or update assets
- ♿️
```
feat
```
  : Improve accessibility
- 💡
```
docs
```
  : Add or update comments in source code
- 🗃️
```
db
```
  : Perform database related changes
- 🔊
```
feat
```
  : Add or update logs
- 🔇
```
fix
```
  : Remove logs
- 🤡
```
test
```
  : Mock things
- 🥚
```
feat
```
  : Add or update an easter egg
- 🙈
```
chore
```
  : Add or update .gitignore file
- 📸
```
test
```
  : Add or update snapshots
- ⚗️
```
experiment
```
  : Perform experiments
- 🚩
```
feat
```
  : Add, update, or remove feature flags
- 💫
```
ui
```
  : Add or update animations and transitions
- ⚰️
```
refactor
```
  : Remove dead code
- 🦺
```
feat
```
  : Add or update code related to validation
- ✈️
```
feat
```
  : Improve offline support

提交前验证：确保代码已通过lint检查、可正常构建，且文档已更新
原子提交：每个提交应包含单一用途的相关变更
拆分大型变更：如果变更涉及多个关注点，将其拆分为独立提交
规范化提交格式：使用
```
<type>: <description>
```
格式，其中type可选值包括：
- ```
feat
```
  ：新增功能
- ```
fix
```
  ：修复bug
- ```
docs
```
  ：文档变更
- ```
style
```
  ：代码样式变更（如格式化等）
- ```
refactor
```
  ：既不修复bug也不新增功能的代码变更
- ```
perf
```
  ：性能优化
- ```
test
```
  ：添加或修复测试
- ```
chore
```
  ：构建流程、工具等变更
现在时、祈使语气：提交信息采用命令式写法（例如："add feature" 而非 "added feature"）
首行简洁：首行长度控制在72字符以内
表情符号：每种提交类型对应合适的表情符号：
- ✨
```
feat
```
  ：新增功能
- 🐛
```
fix
```
  ：修复bug
- 📝
```
docs
```
  ：文档变更
- 💄
```
style
```
  ：格式化/样式调整
- ♻️
```
refactor
```
  ：代码重构
- ⚡️
```
perf
```
  ：性能优化
- ✅
```
test
```
  ：测试相关
- 🔧
```
chore
```
  ：工具、配置变更
- 🚀
```
ci
```
  ：CI/CD优化
- 🗑️
```
revert
```
  ：回滚变更
- 🧪
```
test
```
  ：添加失败测试
- 🚨
```
fix
```
  ：修复编译器/linter警告
- 🔒️
```
fix
```
  ：修复安全问题
- 👥
```
chore
```
  ：添加或更新贡献者
- 🚚
```
refactor
```
  ：移动或重命名资源
- 🏗️
```
refactor
```
  ：架构调整
- 🔀
```
chore
```
  ：合并分支
- 📦️
```
chore
```
  ：添加或更新编译文件/包
- ➕
```
chore
```
  ：添加依赖
- ➖
```
chore
```
  ：移除依赖
- 🌱
```
chore
```
  ：添加或更新种子文件
- 🧑‍💻
```
chore
```
  ：提升开发者体验
- 🧵
```
feat
```
  ：添加或更新多线程/并发相关代码
- 🔍️
```
feat
```
  ：优化SEO
- 🏷️
```
feat
```
  ：添加或更新类型定义
- 💬
```
feat
```
  ：添加或更新文本与字面量
- 🌐
```
feat
```
  ：国际化与本地化
- 👔
```
feat
```
  ：添加或更新业务逻辑
- 📱
```
feat
```
  ：响应式设计开发
- 🚸
```
feat
```
  ：提升用户体验/可用性
- 🩹
```
fix
```
  ：非关键问题的简单修复
- 🥅
```
fix
```
  ：错误捕获处理
- 👽️
```
fix
```
  ：因外部API变更更新代码
- 🔥
```
fix
```
  ：移除代码或文件
- 🎨
```
style
```
  ：优化代码结构/格式
- 🚑️
```
fix
```
  ：紧急热修复
- 🎉
```
chore
```
  ：项目初始化
- 🔖
```
chore
```
  ：发布/版本标签
- 🚧
```
wip
```
  ：进行中工作
- 💚
```
fix
```
  ：修复CI构建问题
- 📌
```
chore
```
  ：固定依赖版本
- 👷
```
ci
```
  ：添加或更新CI构建系统
- 📈
```
feat
```
  ：添加或更新分析/追踪代码
- ✏️
```
fix
```
  ：修复拼写错误
- ⏪️
```
revert
```
  ：回滚变更
- 📄
```
chore
```
  ：添加或更新许可证
- 💥
```
feat
```
  ：引入破坏性变更
- 🍱
```
assets
```
  ：添加或更新资源
- ♿️
```
feat
```
  ：提升可访问性
- 💡
```
docs
```
  ：添加或更新源代码注释
- 🗃️
```
db
```
  ：数据库相关变更
- 🔊
```
feat
```
  ：添加或更新日志
- 🔇
```
fix
```
  ：移除日志
- 🤡
```
test
```
  ：模拟相关内容
- 🥚
```
feat
```
  ：添加或更新彩蛋
- 🙈
```
chore
```
  ：添加或更新.gitignore文件
- 📸
```
test
```
  ：添加或更新快照
- ⚗️
```
experiment
```
  ：实验性操作
- 🚩
```
feat
```
  ：添加、更新或移除功能开关
- 💫
```
ui
```
  ：添加或更新动画与过渡效果
- ⚰️
```
refactor
```
  ：移除死代码
- 🦺
```
feat
```
  ：添加或更新验证相关代码
- ✈️
```
feat
```
  ：优化离线支持

Guidelines for Splitting Commits

提交拆分指南

When analyzing the diff, consider splitting commits based on these criteria:

Different concerns: Changes to unrelated parts of the codebase
Different types of changes: Mixing features, fixes, refactoring, etc.
File patterns: Changes to different types of files (e.g., source code vs documentation)
Logical grouping: Changes that would be easier to understand or review separately
Size: Very large changes that would be clearer if broken down

分析diff时，可根据以下标准拆分提交：

关注点不同：代码库中无关部分的变更
变更类型不同：混合了功能、修复、重构等不同类型的变更
文件类型不同：不同类型文件的变更（如源代码 vs 文档）
逻辑分组：分开理解或评审更清晰的变更
大小问题：过大的拆分为多个小提交更清晰

Examples

示例

Good commit messages:

✨ feat: add user authentication system
🐛 fix: resolve memory leak in rendering process
📝 docs: update API documentation with new endpoints
♻️ refactor: simplify error handling logic in parser
🚨 fix: resolve linter warnings in component files
🧑‍💻 chore: improve developer tooling setup process
👔 feat: implement business logic for transaction validation
🩹 fix: address minor styling inconsistency in header
🚑️ fix: patch critical security vulnerability in auth flow
🎨 style: reorganize component structure for better readability
🔥 fix: remove deprecated legacy code
🦺 feat: add input validation for user registration form
💚 fix: resolve failing CI pipeline tests
📈 feat: implement analytics tracking for user engagement
🔒️ fix: strengthen authentication password requirements
♿️ feat: improve form accessibility for screen readers

Example of splitting commits:

First commit: ✨ feat: add new solc version type definitions
Second commit: 📝 docs: update documentation for new solc versions
Third commit: 🔧 chore: update package.json dependencies
Fourth commit: 🏷️ feat: add type definitions for new API endpoints
Fifth commit: 🧵 feat: improve concurrency handling in worker threads
Sixth commit: 🚨 fix: resolve linting issues in new code
Seventh commit: ✅ test: add unit tests for new solc version features
Eighth commit: 🔒️ fix: update dependencies with security vulnerabilities

优秀的提交信息：

✨ feat: 添加用户认证系统
🐛 fix: 修复渲染过程中的内存泄漏
📝 docs: 更新API文档新增接口
♻️ refactor: 简化解析器中的错误处理逻辑
🚨 fix: 修复组件文件中的linter警告
🧑‍💻 chore: 优化开发者工具配置流程
👔 feat: 实现交易验证业务逻辑
🩹 fix: 修复头部样式的微小不一致
🚑️ fix: 修复认证流程中的严重安全漏洞
🎨 style: 重组组件结构提升可读性
🔥 fix: 移除已废弃的遗留代码
🦺 feat: 为用户注册表单添加输入验证
💚 fix: 修复CI流水线测试失败问题
📈 feat: 实现用户参与度分析追踪
🔒️ fix: 强化认证密码要求
♿️ feat: 提升表单对屏幕阅读器的可访问性

提交拆分示例：

第一个提交：✨ feat: 新增solc版本类型定义
第二个提交：📝 docs: 更新solc新版本相关文档
第三个提交：🔧 chore: 更新package.json依赖
第四个提交：🏷️ feat: 新增API接口类型定义
第五个提交：🧵 feat: 优化工作线程的并发处理
第六个提交：🚨 fix: 修复新增代码中的lint问题
第七个提交：✅ test: 新增solc版本功能单元测试
第八个提交：🔒️ fix: 更新存在安全漏洞的依赖

Command Options

命令选项

```
--no-verify
```
: Skip running the pre-commit checks (lint, build, generate:docs)

```
--no-verify
```
: 跳过预提交检查（lint、build、generate:docs）

Branch Naming Convention

分支命名规范

When committing on

master

main

, the command will ask if you want to create a new branch. If yes, it creates a branch following this pattern:

<type>/<git-username>/<description>

Components:

```
<type>
```
: The commit type (feature, fix, docs, refactor, perf, test, chore, etc.)
```
<git-username>
```
: Your git username (obtained from
```
git config user.name
```
or the system username)
```
<description>
```
: A kebab-case description of the change (e.g.,
```
add-user-auth
```
,
```
fix-login-bug
```
)

Examples:

```
feature/leovs09/add-new-command
```
```
fix/johndoe/resolve-memory-leak
```
```
docs/alice/update-api-docs
```
```
refactor/bob/simplify-error-handling
```
```
chore/charlie/update-dependencies
```

Workflow:

Command detects you're on
```
master
```
or
```
main
```
Asks: "You're on the main branch. Do you want to create a separate branch?"
If "No": Proceeds with commit on current branch
If "Yes": Analyzes your changes to determine the type, asks for a brief description, creates the branch, and proceeds with commit

当在

master

或

main

分支上提交时，命令会询问你是否要创建新分支。若选择是，则按照以下格式创建分支：

<type>/<git-username>/<description>

组成部分：

```
<type>
```
: 提交类型（feature、fix、docs、refactor、perf、test、chore等）
```
<git-username>
```
: 你的Git用户名（从
```
git config user.name
```
或系统用户名获取）
```
<description>
```
: 变更的短横线命名描述（例如：
```
add-user-auth
```
、
```
fix-login-bug
```
）

示例：

```
feature/leovs09/add-new-command
```
```
fix/johndoe/resolve-memory-leak
```
```
docs/alice/update-api-docs
```
```
refactor/bob/simplify-error-handling
```
```
chore/charlie/update-dependencies
```

工作流程：

命令检测到你处于
```
master
```
或
```
main
```
分支
询问："你当前在主分支上，是否要创建单独分支？"
若选择"否"：继续在当前分支提交
若选择"是"：分析你的变更确定类型，询问简短描述，创建分支后继续提交

Important Notes

重要说明

By default, pre-commit checks (
```
pnpm lint
```
,
```
pnpm build
```
,
```
pnpm generate:docs
```
) will run to ensure code quality
If these checks fail, you'll be asked if you want to proceed with the commit anyway or fix the issues first
If specific files are already staged, the command will only commit those files
If no files are staged, it will automatically stage all modified and new files
The commit message will be constructed based on the changes detected
Before committing, the command will review the diff to identify if multiple commits would be more appropriate
If suggesting multiple commits, it will help you stage and commit the changes separately
Always reviews the commit diff to ensure the message matches the changes

默认会运行预提交检查（
```
pnpm lint
```
、
```
pnpm build
```
、
```
pnpm generate:docs
```
）以确保代码质量
如果检查失败，会询问你是否要继续提交或先修复问题
如果已有特定文件被暂存，命令只会提交这些文件
如果没有文件被暂存，会自动暂存所有修改和新增文件
提交信息会根据检测到的变更生成
提交前会检查diff，确认是否适合拆分为多个提交
若建议拆分提交，会协助你分别暂存和提交变更
始终会检查提交diff，确保提交信息与变更内容匹配