Conventional Commits Reference
Complete reference for Conventional Commits specification. Learn commit types, scopes, breaking changes, and examples for semantic versioning workflows.
Loading tool...
How to Use Conventional Commits Reference
- Choose the appropriate type (feat, fix, docs, etc.) for your change
- Optionally add a scope in parentheses to specify what was changed: feat(auth):
- Write a short imperative description: "add login button" not "added login button"
- For breaking changes, add ! after type/scope or include BREAKING CHANGE: in footer
- Add a longer body after a blank line for complex changes
- Reference issues in the footer: Closes #123 or Fixes #456
About Conventional Commits Reference
The Conventional Commits specification provides a lightweight convention on top of commit messages, giving an explicit standard for creating readable history and automating version management.
Conventional Commits Format: `<type>[optional scope]: <description>` `[optional body]` `[optional footer(s)]`
Core Commit Types: - feat: A new feature (triggers MINOR version bump) - fix: A bug fix (triggers PATCH version bump) - docs: Documentation changes only - style: Formatting, missing semicolons — no logic change - refactor: Code restructuring without feature/fix - perf: Performance improvement - test: Adding or correcting tests - build: Build system or dependency changes - ci: CI/CD configuration changes - chore: Routine tasks (updating .gitignore, etc.) - revert: Reverts a previous commit
Breaking Changes: Add `!` after the type/scope, or include `BREAKING CHANGE:` in the footer to trigger a MAJOR version bump: `feat!: rename API endpoints`
Why Use Conventional Commits: Conventional Commits enable automatic changelog generation, semantic versioning, and clear project history. Tools like `semantic-release`, `standard-version`, and `changesets` use these conventions to automate releases entirely.
Common Use Cases
Frequently Asked Questions
What is the difference between feat and fix?
feat introduces new functionality that users can interact with. fix corrects existing behavior that was broken or wrong. In semantic versioning, feat triggers a minor bump (1.1.0 → 1.2.0) and fix triggers a patch bump (1.1.0 → 1.1.1).
When should I use a scope?
Scopes are optional but useful in larger projects. Use them to specify which part of the codebase changed: feat(auth), fix(api), docs(readme). Keep scopes short and consistent across the team.
How do I mark a breaking change?
Either add ! after the type: feat!: rename endpoints, or add BREAKING CHANGE: description in the commit footer. Both trigger a MAJOR semantic version bump.
Can I use multiple types in one commit?
Best practice is one type per commit. If a commit genuinely includes both a feature and a fix, consider splitting it. If you must combine, use the most significant type (feat over fix).
Do I need a tool to enforce conventional commits?
Not required, but tools like commitlint + husky enforce the standard automatically in CI. For individual use, plugins exist for VS Code (Conventional Commits), JetBrains IDEs, and git hooks.
Related Tools
SemVer Calculator
Calculate the next semantic version after a patch, minor, or major bump. Compare two versions. Check if a version satisfies a range like ^1.4.0. Free, no signup.
Diff Checker
Compare two files or texts online free — no paywall, no signup. Highlights additions, deletions, and changes line by line. Works for code, configs, documents.
Hash Generator
Generate MD5, SHA-1, SHA-256, and SHA-512 hashes from text instantly. Verify file integrity, store passwords securely. Free cryptographic hash tool.