Conventional Commits & Semantic Versioning
Intermediatev1.0.0
Implement conventional commit messages that enable automated changelog generation, semantic versioning, and clear project history.
Content
Overview
Conventional Commits is a specification for writing standardized commit messages that are both human-readable and machine-parseable. When combined with semantic versioning, it enables automated changelogs, release notes, and version bumping.
The Format
Commit Types
| Type | When to Use | Version Bump |
|---|---|---|
| `feat` | New feature | MINOR (1.x.0) |
| `fix` | Bug fix | PATCH (1.0.x) |
| `docs` | Documentation only | None |
| `style` | Formatting, no code change | None |
| `refactor` | Code restructure, no behavior change | None |
| `perf` | Performance improvement | PATCH |
| `test` | Adding or fixing tests | None |
| `chore` | Build process, dependencies | None |
| `ci` | CI configuration changes | None |
| `revert` | Reverting a previous commit | Depends |
Breaking Changes
Real Examples
Tooling Setup
Best Practices
- -Keep subject line under 72 characters
- -Use imperative mood: "Add feature" not "Added feature"
- -One logical change per commit
- -Reference issue numbers in footer:
Refs: #123 - -Use body to explain WHY, not WHAT (the diff shows what changed)
Common Mistakes
- -Mixing unrelated changes in one commit
- -Using past tense ("Fixed", "Added") instead of imperative ("Fix", "Add")
- -Commit messages that describe the file changed, not the behavior
- -Forgetting to add scope for large projects
FAQ
Discussion
Loading comments...