← 返回
开发者工具

Conventional Commits

Format commit messages using the Conventional Commits specification. Use when creating commits, writing commit messages, or when the user mentions commits, git commits, or commit messages. Ensures commits follow the standard format for automated tooling, changelog generation, and semantic versioning.
使用 Conventional Commits 规范格式化提交信息。适用于创建提交、编写提交信息,或用户提及提交及 Git 提交时。确保提交遵循标准格式,以支持自动化工具、变更日志生成及语义化版本控制。
bastos
开发者工具 clawhub v1.0.1 1 版本 99550.7 Key: 无需
★ 4
Stars
📥 9,225
下载
💾 1,309
安装
1
版本
#latest

概述

Conventional Commits

Format all commit messages according to the Conventional Commits specification. This enables automated changelog generation, semantic versioning, and better commit history.

Format Structure

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Commit Types

Required Types

  • feat: - A new feature (correlates with MINOR in Semantic Versioning)
  • fix: - A bug fix (correlates with PATCH in Semantic Versioning)

Common Additional Types

  • docs: - Documentation only changes
  • style: - Code style changes (formatting, missing semicolons, etc.)
  • refactor: - Code refactoring without bug fixes or new features
  • perf: - Performance improvements
  • test: - Adding or updating tests
  • build: - Build system or external dependencies changes
  • ci: - CI/CD configuration changes
  • chore: - Other changes that don't modify src or test files
  • revert: - Reverts a previous commit

Scope

An optional scope provides additional contextual information about the section of the codebase:

feat(parser): add ability to parse arrays
fix(auth): resolve token expiration issue
docs(readme): update installation instructions

Description

  • Must immediately follow the colon and space after the type/scope
  • Use imperative mood ("add feature" not "added feature" or "adds feature")
  • Don't capitalize the first letter
  • No period at the end
  • Keep it concise (typically 50-72 characters)

Body

  • Optional longer description providing additional context
  • Must begin one blank line after the description
  • Can consist of multiple paragraphs
  • Explain the "what" and "why" of the change, not the "how"

Breaking Changes

Breaking changes can be indicated in two ways:

1. Using ! in the type/scope

feat!: send an email to the customer when a product is shipped
feat(api)!: send an email to the customer when a product is shipped

2. Using BREAKING CHANGE footer

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

3. Both methods

chore!: drop support for Node 6

BREAKING CHANGE: use JavaScript features not available in Node 6.

Examples

Simple feature

feat: add user authentication

Feature with scope

feat(auth): add OAuth2 support

Bug fix with body

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Breaking change

feat!: migrate to new API client

BREAKING CHANGE: The API client interface has changed. All methods now
return Promises instead of using callbacks.

Documentation update

docs: correct spelling of CHANGELOG

Multi-paragraph body with footers

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

Guidelines

  1. Always use a type - Every commit must start with a type followed by a colon and space
  2. Use imperative mood - Write as if completing the sentence "If applied, this commit will..."
  3. Be specific - The description should clearly communicate what changed
  4. Keep it focused - One logical change per commit
  5. Use scopes when helpful - Scopes help categorize changes within a codebase
  6. Document breaking changes - Always indicate breaking changes clearly

Semantic Versioning Correlation

  • fix: → PATCH version bump (1.0.0 → 1.0.1)
  • feat: → MINOR version bump (1.0.0 → 1.1.0)
  • BREAKING CHANGE → MAJOR version bump (1.0.0 → 2.0.0)

When to Use

Use this format for:

  • All git commits
  • Commit message generation
  • Pull request merge commits
  • When the user asks about commit messages or git commits

Common Mistakes to Avoid

Added new feature (past tense, capitalized)

feat: add new feature (imperative, lowercase)

fix: bug (too vague)

fix: resolve null pointer exception in user service

feat: add feature (redundant)

feat: add user profile page

feat: Added OAuth support. (past tense, period)

feat: add OAuth support

版本历史

共 1 个版本

  • v1.0.1 当前
    2026-03-27 23:33 安全 安全

安全检测

腾讯云安全 (Keen)

安全,无风险
查看报告

腾讯云安全 (Sanbu)

安全,无风险
查看报告

🔗 相关推荐

developer-tools

Github

steipete
使用 `gh` CLI 与 GitHub 交互,通过 `gh issue`、`gh pr`、`gh run` 和 `gh api` 管理议题、PR、CI 运行及高级查询。
★ 666 📥 323,783
productivity

Obsidian Daily

bastos
通过 obsidian-cli 管理 Obsidian 日记笔记。支持创建、打开日记,追加条目(日志、记录、任务、链接),按日期查阅历史笔记及搜索库内容。支持“昨天”、“上周五”、“3天前”等相对日期。
★ 5 📥 6,985
developer-tools

CodeConductor.ai

larsonreever
AI驱动平台,提供快速全栈开发、智能体、工作流自动化及低代码AI集成的可扩展产品创建。
★ 65 📥 179,830