Git Commit Message Helper generates well-structured git commit messages following the Conventional Commits specification. Enter a type (feat, fix, docs, style, refactor, perf, test, chore), an optional scope, a subject line, a body, and breaking change notes — the helper formats the full message according to the spec, validates the subject length, and provides the git commit command ready to copy.
Conventional Commits is a specification for adding human and machine-readable meaning to commit messages. Format: type(scope): subject. Types: feat (new feature), fix (bug fix), docs (documentation), style (formatting), refactor (code restructuring), perf (performance), test (adding tests), chore (maintenance). Breaking changes: add BREAKING CHANGE: in the footer or ! after the type (feat!: or fix!:). This enables automated changelog generation and semantic versioning.
Good commit messages aid code archaeology — understanding why a change was made months later. The 50/72 rule: subject line under 50 characters (shown in git log --oneline), body lines wrapped at 72 characters. Write the subject in imperative mood ('Add feature' not 'Added feature'). The body answers: what changed, why it changed, and any alternatives considered. Each commit should represent a single logical change.
New feature commit
Result: feat(auth): add OAuth2 Google login / Body: Implements RFC 6749 authorization code flow
Bug fix with scope
Result: fix(api): handle null response from payment gateway / Closes #1234
Breaking change
Result: feat(api)!: remove v1 endpoints / BREAKING CHANGE: /api/v1/* removed, use /api/v2/*
What is Conventional Commits?
Conventional Commits is a specification (conventionalcommits.org) that adds semantic meaning to commit messages. The format: type(scope): description — where type is feat, fix, docs, style, refactor, perf, test, or chore. This enables automated tools: semantic-release generates version numbers (patch for fix, minor for feat, major for BREAKING CHANGE). standard-version generates changelogs. CommitLint validates commits in CI.
What is the 50/72 rule for commit messages?
Subject line: 50 characters or fewer. GitHub truncates subjects over 72 characters in the UI. Many git GUIs (GitKraken, SourceTree) show the subject in a fixed-width list — long subjects are cut off. The body (blank line after subject) should wrap at 72 characters per line — this keeps git log output readable in 80-column terminals. These are conventions, not hard limits, but following them improves readability across tools.
Why write commit messages in imperative mood?
Imperative mood (Add, Fix, Update, Remove) matches how git itself describes commits: 'Merge branch', 'Revert commit'. It's shorter than past tense ('Added' → 'Add'). It reads as a command on the codebase. Read the subject as: 'If applied, this commit will [subject].' — 'If applied, this commit will Add OAuth login' reads naturally. Past tense ('Added OAuth login') is also common in practice and not wrong, just not the convention.
How do I write a good commit body?
Answer: what changed, why it changed, and what you considered. Example: 'Replace jQuery AJAX calls with fetch() API. jQuery was the only jQuery dependency remaining. This reduces bundle size by 87 KB (minified+gzipped). Considered axios but the native fetch API is sufficient for our use cases and requires no additional dependency.' Reference related issues, PRs, or RFC links. Explain the 'why', not just the 'what' — the diff already shows what changed.
How do I fix the last commit message?
If you haven't pushed: git commit --amend (opens editor to change the message) or git commit --amend -m 'New message'. If you've already pushed: git commit --amend, then git push --force-with-lease (safer than --force, fails if someone else pushed). Warning: rewriting pushed commits rewrites history. Only do this on feature branches you own, never on shared branches like main. For older commits: git rebase -i HEAD~N to interactively edit the last N commits.