Back to Details

commit-message-generator

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Commit Message Generator

提交信息生成器

Generate clear, conventional commit messages from git diffs.
从git diff生成清晰、符合规范的提交信息。

Quick Start

快速开始

Analyze staged changes and generate message:
bash
git diff --staged
分析已暂存的变更并生成提交信息：
bash
git diff --staged

Then generate message following conventional commits format

然后生成符合Conventional Commits格式的信息

undefined
undefined

Instructions

操作步骤

Step 1: Analyze Changes

步骤1：分析变更内容

Review the git diff to understand:
  • What files changed
  • What functionality was added/modified/removed
  • Scope of changes (component, module, feature)
  • Breaking changes or deprecations
bash
git diff --staged
查看git diff以了解：
  • 哪些文件发生了变更
  • 新增/修改/移除了哪些功能
  • 变更的范围（组件、模块、功能）
  • 是否存在破坏性变更或废弃内容
bash
git diff --staged

or for specific files

或者针对特定文件

git diff --staged path/to/file
undefined
git diff --staged path/to/file
undefined

Step 2: Determine Commit Type

步骤2：确定提交类型

feat: New feature
  • Adding new functionality
  • New user-facing capability
  • New API endpoint
fix: Bug fix
  • Fixing a bug
  • Correcting behavior
  • Resolving an issue
docs: Documentation
  • README updates
  • Code comments
  • API documentation
style: Code style
  • Formatting changes
  • Missing semicolons
  • Whitespace changes
  • No code logic changes
refactor: Code refactoring
  • Restructuring code
  • No functionality change
  • Performance improvements
test: Tests
  • Adding tests
  • Updating tests
  • Test infrastructure
chore: Maintenance
  • Dependency updates
  • Build configuration
  • CI/CD changes
  • Tooling updates
perf: Performance
  • Performance improvements
  • Optimization changes
ci: CI/CD
  • CI configuration
  • Build scripts
  • Deployment changes
build: Build system
  • Build tool changes
  • External dependencies
revert: Revert
  • Reverting previous commit
feat：新功能
  • 新增功能
  • 新增面向用户的能力
  • 新增API端点
fix：Bug修复
  • 修复Bug
  • 修正行为
  • 解决问题
docs：文档更新
  • README更新
  • 代码注释
  • API文档
style：代码风格
  • 格式调整
  • 补充分号
  • 空白字符变更
  • 无代码逻辑变更
refactor：代码重构
  • 代码结构调整
  • 无功能变更
  • 性能优化
test：测试相关
  • 添加测试用例
  • 更新测试
  • 测试基础设施调整
chore：维护工作
  • 依赖更新
  • 构建配置调整
  • CI/CD变更
  • 工具更新
perf：性能优化
  • 性能提升
  • 优化变更
ci：CI/CD相关
  • CI配置调整
  • 构建脚本变更
  • 部署变更
build：构建系统
  • 构建工具变更
  • 外部依赖调整
revert：回滚提交
  • 回滚之前的提交

Step 3: Identify Scope

步骤3：确定变更范围

Scope indicates what part of codebase changed:
  • Component name: 
    (button)
    , 
    (navbar)
  • Module name: 
    (auth)
    , 
    (api)
  • Feature area: 
    (payments)
    , 
    (search)
  • Package name: 
    (core)
    , 
    (utils)
Optional but recommended for clarity.
范围用于指示代码库中变更的部分：
  • 组件名称：
    (button)
    , 
    (navbar)
  • 模块名称：
    (auth)
    , 
    (api)
  • 功能区域：
    (payments)
    , 
    (search)
  • 包名称：
    (core)
    , 
    (utils)
可选，但推荐使用以提升清晰度。

Step 4: Write Description

步骤4：编写描述内容

Subject line (first line):
  • Use imperative mood ("add" not "added")
  • No period at end
  • Max 50-72 characters
  • Lowercase after type
  • Clear and concise
Body (optional, after blank line):
  • Explain what and why, not how
  • Wrap at 72 characters
  • Use bullet points for multiple changes
  • Reference issues/tickets
Footer (optional):
  • Breaking changes: 
    BREAKING CHANGE: description
  • Issue references: 
    Closes #123
    , 
    Fixes #456
  • Co-authors: 
    Co-authored-by: Name <email>
主题行（第一行）：
  • 使用祈使语气（用“add”而非“added”）
  • 结尾不加句号
  • 长度控制在50-72字符
  • 类型后使用小写
  • 清晰简洁
正文（可选，空行后）：
  • 解释变更的内容和原因，而非实现方式
  • 每行不超过72字符
  • 多项变更使用项目符号
  • 关联相关问题/工单
页脚（可选）：
  • 破坏性变更：
    BREAKING CHANGE: description
  • 问题关联：
    Closes #123
    , 
    Fixes #456
  • 共同作者：
    Co-authored-by: Name <email>

Step 5: Format Message

步骤5：格式化提交信息

Basic format:
<type>(<scope>): <description>

[optional body]

[optional footer]
Examples:
feat(auth): add JWT token refresh mechanism

Implement automatic token refresh when access token expires.
Tokens are refreshed 5 minutes before expiration.

Closes #234
fix(api): handle null response in user endpoint

Previously crashed when user data was null.
Now returns 404 with appropriate error message.

Fixes #567
docs(readme): update installation instructions

Add prerequisites section and troubleshooting guide.
refactor(utils): simplify date formatting logic

Extract common date operations into helper functions.
No functionality changes.
chore(deps): upgrade react to v18.2.0

Update react and react-dom dependencies.
Update tests to match new API.
基础格式：
<type>(<scope>): <description>

[可选正文]

[可选页脚]
示例：
feat(auth): add JWT token refresh mechanism

Implement automatic token refresh when access token expires.
Tokens are refreshed 5 minutes before expiration.

Closes #234
fix(api): handle null response in user endpoint

Previously crashed when user data was null.
Now returns 404 with appropriate error message.

Fixes #567
docs(readme): update installation instructions

Add prerequisites section and troubleshooting guide.
refactor(utils): simplify date formatting logic

Extract common date operations into helper functions.
No functionality changes.
chore(deps): upgrade react to v18.2.0

Update react and react-dom dependencies.
Update tests to match new API.

Common Patterns

常见模式

Multiple changes in one commit:
feat(dashboard): add user analytics and export

- Add analytics charts for user activity
- Implement CSV export functionality
- Add date range filter

Closes #123, #124
Breaking change:
feat(api)!: change authentication endpoint structure

BREAKING CHANGE: Auth endpoints now use /v2/auth prefix.
Update client code to use new endpoints.

Migration guide: docs/migration-v2.md
Revert commit:
revert: feat(auth): add JWT token refresh

This reverts commit abc123def456.
Reason: Causing issues in production.
Co-authored commit:
feat(search): implement fuzzy search algorithm

Co-authored-by: Jane Doe <jane@example.com>
单次提交包含多项变更：
feat(dashboard): add user analytics and export

- Add analytics charts for user activity
- Implement CSV export functionality
- Add date range filter

Closes #123, #124
破坏性变更：
feat(api)!: change authentication endpoint structure

BREAKING CHANGE: Auth endpoints now use /v2/auth prefix.
Update client code to use new endpoints.

Migration guide: docs/migration-v2.md
回滚提交：
revert: feat(auth): add JWT token refresh

This reverts commit abc123def456.
Reason: Causing issues in production.
共同作者提交：
feat(search): implement fuzzy search algorithm

Co-authored-by: Jane Doe <jane@example.com>

Commit Message Quality

提交信息质量

Good commit messages:
  • Clear and descriptive
  • Explain why, not just what
  • Reference related issues
  • Follow conventions consistently
  • Atomic (one logical change)
Bad commit messages:
  • "fix stuff"
  • "WIP"
  • "updates"
  • "asdf"
  • "fix fix fix"
优质提交信息：
  • 清晰描述
  • 解释原因而非仅内容
  • 关联相关问题
  • 始终遵循规范
  • 原子化（单一逻辑变更）
劣质提交信息：
  • "fix stuff"
  • "WIP"
  • "updates"
  • "asdf"
  • "fix fix fix"

Workflow Integration

工作流集成

Before committing:

提交前：

  1. Review changes: 
    git diff --staged
  2. Ensure changes are atomic
  3. Generate appropriate message
  4. Commit: 
    git commit -m "type(scope): description"
  1. 查看变更：
    git diff --staged
  2. 确保变更为原子化
  3. 生成合适的提交信息
  4. 提交：
    git commit -m "type(scope): description"

For detailed commits:

详细提交：

  1. Stage changes: 
    git add files
  2. Open editor: 
    git commit
  3. Write multi-line message
  4. Save and close
  1. 暂存变更：
    git add files
  2. 打开编辑器：
    git commit
  3. 编写多行提交信息
  4. 保存并关闭

Amending last commit:

修正最后一次提交：

bash
git commit --amend
bash
git commit --amend

Edit message in editor

在编辑器中修改提交信息

undefined
undefined

Interactive staging:

交互式暂存：

bash
git add -p  # Stage hunks interactively
git commit  # Write message for staged changes
bash
git add -p  # 交互式暂存代码块
git commit  # 为暂存的变更编写提交信息

Conventional Commits Spec

Conventional Commits 规范

Format: 
<type>[optional scope]: <description>
Required:
  • type: Must be one of the defined types
  • description: Brief summary of change
Optional:
  • scope: Component/module affected
  • body: Detailed explanation
  • footer: Breaking changes, issue references
Rules:
  • Type must be lowercase
  • Scope in parentheses
  • Colon and space after scope
  • Description starts lowercase
  • No period at end of description
  • Body separated by blank line
  • Footer separated by blank line
格式：
<type>[optional scope]: <description>
必填项：
  • type：必须为定义的类型之一
  • description：变更的简要总结
可选项：
  • scope：受影响的组件/模块
  • body：详细说明
  • footer：破坏性变更、问题关联
规则：
  • Type必须为小写
  • Scope放在括号内
  • Scope后加冒号和空格
  • Description开头小写
  • Description结尾不加句号
  • Body与主题行之间空一行
  • Footer与Body之间空一行

Advanced

进阶内容

For complex scenarios:
  • Multi-commit features
  • Monorepo commit conventions
  • Automated commit message validation
  • Commit message templates
  • Semantic versioning integration
针对复杂场景：
  • 多提交功能开发
  • 单体仓库提交规范
  • 提交信息自动验证
  • 提交信息模板
  • 语义化版本集成