Git Commit Message Generator: Turn Any Diff into a Clean Commit
Describe your changes or paste a diff and get a clear, professional commit message following Conventional Commits. Free, no account required.
Shipping Several PRs a Day?
With Pro, even sprawling multi-file diffs fit in a single request, and responses come back faster.
AI Git Commit Message Generator Following Conventional Commits
A good commit message tells the next developer (and future you) why a change was made, not just what files changed. The diff already shows what changed. The commit message is for context, motivation, and searchability. Our AI generator produces commit messages that follow the Conventional Commits specification - with the right type (feat, fix, refactor, chore), an accurate scope, and a concise subject line under 72 characters.
Paste the output of git diff --staged for the most accurate result, or describe your changes in plain English. The AI infers the correct type and writes a message you can commit with confidence. For reviewing the code that goes along with the commit, try our Code Explainer. For testing the code before committing, use our Unit Test Generator.
Commit Types Generated
Why Good Commit Messages Matter
A commit log is a timeline of decisions. When something breaks six months from now, the person debugging it will read through git blame and git log to understand why code was written a certain way.
Conventional Commits makes git log --grep useful. Find every feature or fix by type and scope instantly.
semantic-release parses Conventional Commits to generate changelogs and bump version numbers automatically.
Reviewers understand intent before opening a single file. A clear commit message cuts review time significantly.
Subject lines kept under 72 characters, imperative mood, with a blank line before any body paragraph.
Paste git diff --staged and the AI reads your actual changes to produce the most accurate message possible.
GitHub-style, Angular-style, and Jira-linked commit formats are all available - just specify your preference.
Conventional Commits Type Reference
The type prefix is the part developers second-guess most. This table covers all ten standard types and when each one applies.
| Type | When to use it |
|---|---|
feat | A new capability users can see or call. Triggers a minor version bump in semantic-release. |
fix | A bug fix that corrects wrong behavior. Triggers a patch version bump. |
docs | Documentation only: README, code comments, API docs. No production code touched. |
style | Formatting, whitespace, semicolons, lint fixes. The code's meaning is unchanged. |
refactor | Code restructuring that neither fixes a bug nor adds a feature, like extracting a function. |
perf | A change whose purpose is making code faster or lighter, such as adding caching. |
test | Adding or correcting tests. Production code is untouched. |
build | Build system or external dependencies: npm packages, webpack config, Dockerfiles. |
ci | CI pipeline configuration: GitHub Actions workflows, Jenkins files, deploy scripts. |
chore | Maintenance that fits nowhere else: bumping versions, updating .gitignore. |
Scopes and Breaking Changes
A scope narrows the type to the area of the codebase affected: feat(auth): add OAuth login or fix(parser): handle empty input. To flag a breaking change, append ! after the type or scope, as in feat(api)!: remove legacy v1 endpoints, and add a BREAKING CHANGE: footer describing the migration. Tools like semantic-release read that marker and cut a major version.
Bad to Good: Three Commit Message Rewrites
The fastest way to internalise the format is seeing weak messages repaired. Each rewrite below adds a type, switches to the imperative mood, and says why, not just what.
Before: updated stuff
After: fix(checkout): prevent double-submit on slow connections
The original tells a future reader nothing. The rewrite names the area, the behavior, and the condition that triggered it.
Before: added some tests and fixed the date bug
After: fix(reports): use UTC when grouping orders by day plus a separate test(reports): cover month-boundary grouping
Two unrelated changes belong in two commits, each in the imperative mood.
Before: change timeout from 30 to 5
After: perf(api): lower upstream timeout to 5s with a body line: "30s timeouts let one slow vendor exhaust the worker pool during peak traffic."
The diff already shows the number changed. The message preserves the reasoning.