Advertisement
Guide
About the Conventional Commit Message Builder
Conventional Commits is a simple format for commit messages: type(scope): description, optionally followed by a body and footers. Because the structure is predictable, tools can generate changelogs and decide version numbers automatically, and humans can scan history faster.
Choose a type, describe the change, and the builder assembles a correctly formatted message and points out anything that would fail a typical commitlint setup.
Types and version numbers
Release tools read the type: fix triggers a patch release, feat a minor release, and any commit marked breaking a major release. Types like docs, chore and ci appear in history without releasing anything.
Writing a good description
Use the imperative mood (“add”, not “added”), keep the first line under about 50 characters, and leave out the full stop. Explain why in the body — the diff already shows what changed.
How to use it
- 1Pick the type of change.
- 2Add an optional scope and a short description.
- 3Add a body, issue numbers or co-authors if needed.
- 4Copy the message or the git commit command.
Frequently asked questions
What is the difference between chore and build?
build is for the build system and dependencies (webpack, package.json). chore is a catch-all for maintenance that touches neither source nor tests.
How do I mark a breaking change?
Add ! after the type or scope, like feat(api)!: …, and explain the change in a BREAKING CHANGE: footer. Either alone counts; using both is clearest.
Do issue footers close GitHub issues?
Yes. “Closes #123” or “Fixes #123” closes the issue when the commit reaches the default branch. “Refs” only links it.
How do I credit a co-author on GitHub?
Add a Co-authored-by: Name <email> trailer using the email on their GitHub account. GitHub shows both avatars on the commit.
How do I enforce this format in my team?
Install commitlint with @commitlint/config-conventional and run it from a commit-msg Git hook (for example with Husky) or in CI.