Conventional Commit Generator

Conventional Commit generator for clear, structured messages

The Conventional Commit generator assembles a commit message in the predictable type(scope): description format. Choose the kind of change, an optional scope, and a concise subject, then add a body, a BREAKING CHANGE note, and issue references when needed. The result is ready for Git and for tools that derive changelogs or release versions from repository history.

Why commit message structure matters

A repository history documents technical decisions. When every contributor describes work differently, it becomes hard to distinguish features from fixes, find changes to one module, or prepare release notes. Conventional Commits introduces a small contract that is easy to remember. The first token states the intent, the scope identifies an area, and the subject explains the outcome. This structure remains readable during review while giving automation an unambiguous signal.

Header, body, and footer anatomy

feat(auth): add passkey sign-in

Support authentication in the mobile application.

BREAKING CHANGE: remove the previous token format

Refs: #123

The header should be short and useful on its own. A type is required, a scope is optional, and an exclamation mark after the type or scope announces an incompatible change. A body after a blank line can explain motivation and consequences. Footers carry the breaking change note and issue links. The generator validates header fields and numeric issue IDs so they cannot inject unexpected lines into the message you copy.

feat, fix, and the other supported types

Scope, imperative subject, and header length

A scope should be a stable name for part of the system, such as auth, api, checkout, or docs. Do not turn it into a ticket number or a sentence. Write the subject in the imperative mood: “add validation,” “fix sorting,” or “remove deprecated option.” The displayed length covers the entire header, including type, parentheses, scope, marker, and separator. Exceeding the selected limit does not destroy the message; it produces a visible warning so you can shorten it deliberately.

BREAKING CHANGE and semantic versioning

An incompatible change needs attention whether its type is feat, fix, or refactor. Enabling the option adds an exclamation mark to the header and a BREAKING CHANGE: footer. Explain what stops working and how consumers should migrate. SemVer-aware automation can map a fix to patch, a feature to minor, and a breaking change to major. The message itself does not publish anything; release behavior belongs to project policy and a pipeline such as one prepared with the GitLab CI generator.

From commit history to changelogs and checks

Consistent messages let tooling filter history, group entries by type, and produce release notes without copying ticket titles by hand. They can also be enforced in a commit-msg hook before a bad message reaches the shared branch. For a new repository, pair that policy with exclusions from the .gitignore generator. In projects with automated tests, ci and build commits fit naturally beside workflows created with the GitHub Actions generator.

How to build a useful message step by step

1. Choose a type from the effect of the change, not from the ticket or branch name.
2. Add a short scope when it identifies a module; omit it for a project-wide change.
3. Write a one-line imperative subject without a trailing period.
4. Use the body to explain motivation, constraints, and decisions that the diff cannot show.
5. Mark a breaking change only when a consumer must change an integration, data, or configuration.
6. Enter comma-separated issue IDs, review the header length, and copy the finished message.

Frequently asked questions