Commit Message Generator

Why conventional commits are worth the discipline

Conventional Commits is a simple format - a type, an optional scope, and a short imperative summary, followed by an optional body and footers. That small amount of structure unlocks a lot: automated changelogs, automated semantic version bumps, commitlint checks in CI, and a git history that a human can actually scan. This generator builds a compliant message from a few fields so you get all of that without memorizing the spec.

The payoff compounds over a project's life. Six months in, a history of 'wip', 'fix stuff', and 'updates' tells you nothing, while a history of 'feat(auth): add password reset' and 'fix(api): handle empty payload' reads like a table of contents. The format costs you almost nothing per commit and pays back every time you or a teammate goes spelunking through the log.

The anatomy of a conventional commit

• Header - type(scope): summary. This is the one required line, and it should stay under about 72 characters so it displays cleanly everywhere.
• Type - what kind of change it is: feat, fix, docs, refactor, perf, test, build, ci, chore, revert, and a few others.
• Scope - an optional area in parentheses, like (auth) or (api), that tells readers which part of the codebase changed.
• Body - optional bullets explaining the what and the why. This is where the reasoning goes, not the header.
• Footers - machine-readable trailers like 'BREAKING CHANGE:' and issue references like 'Closes #123'.

Picking the right type

1. feat - you added a capability a user can see or use. This drives a minor version bump under semantic versioning.
2. fix - you corrected a bug. This drives a patch version bump.
3. refactor - you changed code structure without changing behavior. No version bump.
4. docs, style, test, build, ci, chore - housekeeping categories that keep the noise out of your changelog.
5. Anything with a breaking change gets the ! marker and a BREAKING CHANGE footer, which drives a major version bump.

Breaking changes deserve a loud footer

A breaking change is any change that forces consumers of your code to update their own. The convention marks these two ways - a ! after the type or scope, and a BREAKING CHANGE: footer describing what broke and how to migrate. Do not bury this in the body. Tooling reads the footer to trigger a major version bump, and the humans downstream read it to know they have work to do. When you check the breaking box here, both markers are added and the migration note goes where tools expect it.

Body and footers: the part people skip

The header says what changed; the body says why. For a trivial change the header is enough. For anything with a non-obvious reason - a workaround, a tradeoff, a decision that will look strange later - a few body bullets are a gift to your future self. Footers carry the structured metadata: issue references that auto-close tickets when merged, and breaking-change notes. Keep the body about the reasoning and the footers about the links, and your log becomes genuinely useful.

Committing multi-line messages cleanly

The quick one-liner this tool emits uses only the header, which is fine for small commits. For a full message with a body and footers, do not try to cram it into repeated -m flags by hand - copy the whole message and paste it into your editor when git opens it, or write it to a file and use git commit -F. Preserving the blank line between the header and the body is what makes the format valid, and pasting the whole block keeps that structure intact.