What's imperative mood?

Subject as if completing the sentence 'If applied, this commit will ___'. So 'add login flow' (correct) vs 'added login flow' or 'adds login flow' (incorrect). The convention comes from git's own conventions (the messages from `git pull` etc. all use imperative). Imperative reads as commands, which is what commits effectively are: instructions to git about what to record.

What's the difference between feat and fix?

feat = new functionality (a new feature, new option, new component). fix = bug fix (correcting incorrect behavior in existing functionality). Edge case: enhancing an existing feature usually counts as feat (new functionality within existing area). Restoring lost behavior after a bug = fix. When in doubt, ask: would users notice this as 'something new' or 'something fixed'?

Should I always include a scope?

Optional but recommended for consistency. Scopes work best when there's a clear module structure (in a monorepo: package names; in a single repo: top-level dirs or feature areas). For very small repos, scopes add noise. Pick a project-wide convention and stick with it.

What's a breaking change?

Anything that would require users / consumers to update their code or configuration to keep working. API removals, renames, signature changes, behavior changes for existing inputs, configuration option removals. semantic-release uses 'BREAKING CHANGE' to trigger a MAJOR version bump (so be careful — it commits you to the breaking-change semantics). Less impactful changes ('this might affect users in edge cases') usually don't warrant the marker.

Should commits be small or large?

Small and focused. One logical change per commit. Adding a feature plus refactoring plus fixing an unrelated bug = three commits, not one. Small commits make code review easier, bisect-debugging easier, and cherry-picking selective changes possible. The team that values small commits ships better software.

What about issue references?

Common conventions: 'fix(auth): handle missing token (#123)' or 'closes #123' in the footer. GitHub auto-closes issues when commits with 'closes #N' or 'fixes #N' are merged to the default branch. Keep the issue reference; it's the link from commit-history back to discussion / planning context.

Developer Utilities · Free tool

Git Commit Message Helper

Free online tool to build conventional-commit messages from type, scope, subject, and body. Paste straight into git commit. No sign-up needed.

Updated June 2026

Type

Scope (optional)

Summary

23 chars (keep subject under 72)

Body (optional)

Breaking change

Issue reference (optional)

feat: short description

Found this useful?Email Buy Me a Coffee

What it does

Compose a Conventional Commits-formatted message with the right type tag, scope, and breaking-change signals. Pick a type (feat / fix / docs / style / refactor / perf / test / build / ci / chore / revert), optionally add a scope (the module or area affected: feat(auth): ...), write a short subject line in imperative mood, optionally add a body and footer for breaking changes. The tool formats the final message ready to paste into git commit -m.

The Conventional Commits specification (conventionalcommits.org) standardizes commit message format with rules:

Type (required): one of feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert. Each type has different semantic meaning.
Scope (optional): the part of the codebase affected, in parentheses: feat(api): ....
Subject: imperative mood (“add login flow” not “added login flow” or “adds login flow”), under 50-72 chars, no trailing period.
Body (optional): blank line, then longer explanation. Why the change, not what (the diff shows what).
Breaking change: footer BREAKING CHANGE: description, OR add ! after type/scope: feat(api)!: rename foo to bar.

Why the format matters: tooling reads commit messages. Semantic-release / standard-version / changesets read your commits to auto-generate CHANGELOG.md and pick the next version (feat = minor bump, fix = patch, BREAKING = major). Without consistent format, automated versioning breaks. Even without automation, scanning history with git log --oneline is much more useful when messages start with type tags.

The convention came from Angular team’s internal commit guidelines (2014) and was formalized as Conventional Commits in 2018-2019. Now standard across many open-source projects, popular npm packages (semantic-release adoption), and many enterprise codebases.

Embed this tool on your siteShow snippet

Paste this snippet into any page. Loads on-demand (lazy), no tracking scripts, and sized to most dashboards. Replace the height to fit your layout.

<iframe src="https://freetoolarena.com/embed/git-commit-message-helper" width="100%" height="720" frameborder="0" loading="lazy" title="Git Commit Message Helper" style="border:1px solid #e2e8f0;border-radius:12px;max-width:720px;"></iframe>

Embed docs →

How to use it

Pick type. Most common: feat (new feature), fix (bug fix), docs (documentation only), refactor (no functional change), test (test changes), chore (config / build / dependencies).
Optionally add scope — the module or area affected. Examples: 'auth', 'api', 'ui', 'cli'. Keep scopes short and consistent across the project.
Write subject. Imperative mood ('add' not 'added'). Under 50 chars ideally; up to 72 if necessary. No trailing period.
Optionally add body for context — blank line after subject, then explain WHY the change (the diff shows WHAT).
If breaking change: tick the breaking-change checkbox. Tool adds BREAKING CHANGE: footer (or '!' after type, depending on convention).
Copy the formatted message. Paste into `git commit -m "..."` or `git commit` then paste in the editor.

When to use this tool

Open-source projects following Conventional Commits.
Repos using semantic-release or standard-version for automated versioning.
Team conventions for commit-message-driven CHANGELOGs.
Personal projects to develop commit-discipline habits.

When not to use it

Repos with established but different conventions — match the existing style. Look at recent commits to learn the style.
WIP / experimental commits that will be squashed before merge — keep them informal; the final squash commit should follow conventions.
Solo personal projects where you don't need the rigor — informal commit messages are fine when nobody else (including future-you) needs to parse them.

Common use cases

Educational use — demonstrating the underlying concept
Onboarding a colleague who needs the same calculation/conversion
Verifying a number or output before passing it on
Quick use during a typical workday

Frequently asked questions

What's imperative mood?: Subject as if completing the sentence 'If applied, this commit will ___'. So 'add login flow' (correct) vs 'added login flow' or 'adds login flow' (incorrect). The convention comes from git's own conventions (the messages from `git pull` etc. all use imperative). Imperative reads as commands, which is what commits effectively are: instructions to git about what to record.
What's the difference between feat and fix?: feat = new functionality (a new feature, new option, new component). fix = bug fix (correcting incorrect behavior in existing functionality). Edge case: enhancing an existing feature usually counts as feat (new functionality within existing area). Restoring lost behavior after a bug = fix. When in doubt, ask: would users notice this as 'something new' or 'something fixed'?
Should I always include a scope?: Optional but recommended for consistency. Scopes work best when there's a clear module structure (in a monorepo: package names; in a single repo: top-level dirs or feature areas). For very small repos, scopes add noise. Pick a project-wide convention and stick with it.
What's a breaking change?: Anything that would require users / consumers to update their code or configuration to keep working. API removals, renames, signature changes, behavior changes for existing inputs, configuration option removals. semantic-release uses 'BREAKING CHANGE' to trigger a MAJOR version bump (so be careful — it commits you to the breaking-change semantics). Less impactful changes ('this might affect users in edge cases') usually don't warrant the marker.
Should commits be small or large?: Small and focused. One logical change per commit. Adding a feature plus refactoring plus fixing an unrelated bug = three commits, not one. Small commits make code review easier, bisect-debugging easier, and cherry-picking selective changes possible. The team that values small commits ships better software.
What about issue references?: Common conventions: 'fix(auth): handle missing token (#123)' or 'closes #123' in the footer. GitHub auto-closes issues when commits with 'closes #N' or 'fixes #N' are merged to the default branch. Keep the issue reference; it's the link from commit-history back to discussion / planning context.

Learn more

Explore more developer utilities tools

100% in-browserNo downloadsNo sign-upMalware-freeHow we keep this safe →