Git Commit Message Generator

The Git Commit Message Generator helps you write clear, consistent commit messages following the Conventional Commits specification — the industry-standard format adopted by Angular, React, Vue, Next.js, and thousands of other projects. Choose a type (feat, fix, docs, chore, refactor, perf, test, build, ci, style, revert), optionally specify a scope (api, ui, db), write the subject in imperative mood, and the tool generates a properly-formatted commit message. Supports multi-line commits with body and footer (for breaking changes, issue references, co-authors).

Conventional Commits power automation — tools like semantic-release, standard-version, and commitlint read commit messages to automatically determine version bumps (fix = patch, feat = minor, BREAKING CHANGE = major), generate CHANGELOG.md files, and enforce commit message rules in CI. Teams using Conventional Commits have cleaner history, auto-generated release notes, and automatic version numbers. This tool bakes in all the rules so you never get "commit rejected by commitlint" errors.

Conventional Commits (specified at https://www.conventionalcommits.org) is a lightweight convention for commit messages.

Format:

```
<type>[optional scope][!]: <description>

[optional body]

[optional footer(s)]
```

Example:
```
feat(api): add user search endpoint

Implements full-text search across users by name and email.
Uses PostgreSQL trigram indexes for performance.

Closes #123
```

Type (required):

Primary types with their semantic meaning:

- feat: — new feature (minor version bump)
- fix: — bug fix (patch version bump)
- docs: — documentation only changes
- chore: — maintenance, dependencies, build changes (no version bump)
- refactor: — code changes that neither fix bugs nor add features
- perf: — performance improvements (patch or minor)
- test: — adding or correcting tests
- build: — build system or dependency changes (npm, Maven, webpack)
- ci: — CI/CD configuration (GitHub Actions, Jenkins, Circle)
- style: — code formatting, whitespace, semicolons (no logic changes)
- revert: — revert a previous commit

Scope (optional):

In parentheses after type. Names a part of the codebase: feat(auth):, fix(api):, docs(readme):. Common scopes: component name, module name, affected package.

Breaking changes:

Indicate with ! after type/scope: feat!: or feat(api)!:. Or explicitly in footer: BREAKING CHANGE: description. Breaking changes trigger major version bump.

Subject (required):

The first line. Rules:

- Imperative mood — "add feature" not "added" or "adds". Matches git default (Merge branch...).
- No period at end.
- Lowercase first word (sometimes — some styles use capital).
- Under 50-72 characters (50 for strict projects, 72 for most).
- Describes what, not how.

Body (optional):

After blank line. Explains why and what more thoroughly. Wrap at 72 characters.

Footer (optional):

References issues, breaking changes, co-authors:

``
Closes #123
BREAKING CHANGE: API endpoint moved from /v1/user to /v2/user
Co-authored-by: Jane Doe <jane@example.com>
Signed-off-by: Alice <alice@example.com>
``

Automation integrations:

- semantic-release: reads commits to determine version bump + generate changelog + publish.
- standard-version: similar to semantic-release but local (no npm publish).
- commitlint: enforces commit message rules in git hooks and CI.
- commitizen: interactive prompt for commit message fields.
- GitHub: shows BREAKING CHANGE footer in release notes.

Version bumping logic (SemVer):

- feat → minor (1.2.0 → 1.3.0)
- fix → patch (1.2.0 → 1.2.1)
- perf → patch
- BREAKING CHANGE or ! → major (1.2.0 → 2.0.0)
- Other types → no version bump

Good vs bad examples:

BAD:
``
updated things
fix stuff
WIP
final v3 (for real)
Merge branch feat-new-thing into main
``

GOOD:
``
feat(auth): add OAuth 2.0 provider support
fix(parser): handle empty JSON arrays correctly
docs: update README with installation steps
chore(deps): bump lodash from 4.17.20 to 4.17.21
``

Conventional Commits vs Angular style: Angular pioneered this style. Conventional Commits is the broader specification that includes Angular style. Same format with small differences. Most projects use Conventional Commits; some stick with original Angular.

Conventional Commits vs Gitmoji: Gitmoji uses emoji prefixes (🚀 for deploy, 🐛 for bug). Visual but less tool-friendly. Conventional Commits is text-based, better for automation. Some projects use both.

Conventional Commits vs free-form: Free-form works but requires discipline to be consistent. Conventional Commits is consistent by default (the format enforces it). Automation (semantic-release) requires conventional.

Subject line length conventions: 50 chars (strict, kernel-style), 72 chars (common limit matching terminal width). 100+ chars is too long — most tools truncate.

Commit format vs PR title format: Commits are individual. PRs aggregate commits. Convention: same conventional format for both. Squash merge = PR title becomes the commit message. Keep PR titles conventional too.

BREAKING CHANGE in body vs footer: Can appear in either. Footer is more standard. Some tools (semantic-release) look for footer specifically.