Conventional commit builder
Compose a well-formed commit message and see the git command and the release bump it implies.
Commit messages that explain themselves
A project's history is documentation: it answers "when did this change and why?" months later. Vague messages ("fix stuff", "updates") waste that. The Conventional Commits convention gives every commit a small, machine-readable structure that humans can scan, and that tools can turn into changelogs and version numbers.
Choose the type, add an optional scope, write a short subject and, if useful, a body that explains the reason for the change. Mark breaking changes and add issue references. The builder assembles the message, shows the full text and the git commit command, tells you which release bump the commit implies, and warns about common slips: a subject that is too long, ends with a period, starts with a capital letter or uses the past tense.
Choosing the type
featadds behavior users can notice;fixcorrects a bug.refactorandperfchange code without changing what it does (perf for speed).docs,test,styletouch only docs, tests or formatting.build,ciandchorecover tooling, pipelines and housekeeping.
The format is a convention, not a rule enforced by Git. Teams enforce it with a commit-msg hook (commitlint) or a pull request title check. Everything is built in your browser.
Frequently asked questions
What is the Conventional Commits format?
A header of type(scope): subject, an optional body and optional footers. The type says what kind of change it is, the optional scope names the area, and a ! after the type or a BREAKING CHANGE: footer marks an incompatible change.
How do commit types relate to versions?
In Semantic Versioning, fix maps to a patch release, feat to a minor release and any breaking change to a major release. Tools such as semantic-release and release-please read the commit history and cut releases automatically.
How long should the subject be?
Keep the first line to about 50 to 72 characters, in the imperative mood ("add login", not "added login"), without a trailing period. Put the explanation in the body.
Where do issue references go?
In the footer, for example Closes: #123. GitHub and GitLab close the issue when the commit reaches the default branch.