Opening a project’s Git history and finding messages like “various fixes,” “update,” or “fixed something” can be a nightmare. That chaos makes it impossible for anyone to understand what actually happened in the code. This is where Conventional Commits come in.
What Are Conventional Commits?
Conventional Commits is a specification that defines how commit messages should be written in Git. Its goal is to create a clearer and more structured commit history.
Each commit follows a predictable pattern that describes the intention behind the change — whether it fixes a bug (fix), adds a new feature (feat), or introduces a breaking change (breaking change).
Structure of a Conventional Commit
A commit is structured as follows:
type>[optional scope]: description>
[optional body]
[optional footer(s)]- Type (
- Scope (optional): indicates which part of the code was modified, such as feat(api) or fix(auth).
- Description: a short, concise summary of the change.
- Body (optional): provides additional context or technical details.
- Footer(s): used for breaking changes, issue references, or approvals.
Most Common Types
| Tipo | Propósito |
|---|---|
| fix | Fixes a bug |
| feat | Adds a new feature |
| docs | Documentation-only changes |
| refactor | Improves code without changing its behavior |
| build | Changes to dependencies or build configuration |
| chore | Routine tasks with no functional impact |
Practical Examples
New feature with scope:
feat(auth): add Google login supportBug fix with details:
fix: handle async error management properly
Added a unique identifier to avoid race conditions.
Refs #133Conclusion
Adopting Conventional Commits isn’t just about writing prettier messages, it’s about improving communication, reducing errors, and automating key parts of your development workflow.
At first, it might feel like an extra rule to remember, but soon you’ll notice your commits becoming more expressive and your workflow more organized.
Next time you write a commit message, ask yourself:
“What kind of change am I making?”
Use feat:, fix:, or docs: and let your commits speak for themselves.