Use the free Conventional Commit Builder below: your data never leaves your browser — all work happens on your device, and nothing is uploaded to any server.
Commit Messages Are Documentation, Not an Afterthought
A commit message is the first thing a teammate reads when they ask why a change was made, and the first thing an automated tool reads when it builds a changelog or decides the next version number. Messages like fixed stuff or updates tell nobody anything, and they break every tool that depends on a predictable format. Conventional Commits solves this with a small, strict structure: a type, an optional scope, a description, and optional body and footer sections.
This builder writes that structure for you. You pick a type such as feat for a new feature or fix for a bug fix, add an optional scope like login or api, write a short description, and add a body or footer when the change needs more explanation. The tool checks the common rules as you go: descriptions over 72 characters, a capital first letter, or a trailing full stop all earn a gentle warning, so the message you copy is one your team and your tools can rely on.
How to Use It
Pick the type, add a scope if the change belongs to one part of the code, write the description, and add a body or footer only when needed. Press Build and copy the finished message.
- Choose the type that fits the change: feat, fix, docs, refactor, and the rest.
- Add a scope if the change touches one area, such as login, api, or checkout.
- Tick Breaking change only if the change breaks existing behaviour for users or other code.
- Write a short description in the imperative mood, such as fix password reset link expiry.
- Add a body for the why, if the description alone does not explain the change.
- Add a footer for references, such as Closes #123, then copy the message.
A Worked Example
A password reset bug is a classic fix: type fix, scope login, description fix password reset link expiry, and the result is fix(login): fix password reset link expiry. If the fix also changes the reset link format in a way that breaks old links, tick Breaking change and the tool adds an exclamation mark and a BREAKING CHANGE footer, which tells versioning tools that this is a major change. A footer like Closes #123 links the commit to the issue it resolves, so the issue closes automatically when the commit is merged.
Tips That Save Time
- Use the imperative mood: fix, add, change, not fixed, added, or changes.
- Keep the description under 72 characters so it displays fully in logs and tools.
- Use the body for the why, not a repeat of the what. The description already says what changed.
- Use feat only for user-visible new features, and fix only for bug fixes, so version numbers are calculated correctly.
- Be consistent. A team that uses the same types and scopes gets changelogs that practically write themselves.
Common Mistakes to Avoid
The most common mistake is using feat for every change, which inflates version numbers and makes changelogs useless. Another is writing a description that only makes sense with inside knowledge, such as fix it again, which helps nobody in six months. A third is marking a change as breaking when it is not, or failing to mark a real breaking change, both of which mislead everyone who depends on the version number. When in doubt, describe the user impact honestly.
Questions People Ask
What is the difference between feat and fix? A feat adds a new feature for users and usually triggers a minor version bump, while a fix corrects a bug and usually triggers a patch bump.
Do I need a scope? No, the scope is optional. Use it when the change belongs clearly to one area, and skip it for broad changes.
Good commit messages take ten seconds longer and save hours later. Build the message here, check the warnings, and commit with a message worth reading.
Related tools
- Crear Mensajes de Commit Convencionales (Spanish version)
- Git Branch Name Generator
- CSS Selector Tester