liminfoGit Commit Generator
Free web tool: Git Commit Generator
0/72 characters
Generated Commit Message
feat: About Git Commit Generator
The Git Commit Message Generator helps developers write well-structured commit messages following the Conventional Commits specification (conventionalcommits.org). You select a commit type from eleven options — feat (new feature), fix (bug fix), docs (documentation), style (code formatting), refactor (code restructuring), test (adding/fixing tests), chore (build/tooling changes), perf (performance improvement), ci (CI configuration), build (build system), or revert (undoing a commit) — add an optional scope in parentheses, write a short description, and optionally add a multi-line body. The tool formats all inputs into the correct Conventional Commits header: type(scope)!: description. The generated message appears in a code block preview and can be copied to the clipboard with one click.
Conventional Commits is a lightweight commit message convention that maps directly to Semantic Versioning. A commit with type feat increments the minor version; a commit with type fix increments the patch version; a commit with a BREAKING CHANGE footer (or a ! after the type/scope) increments the major version. By enabling the Breaking Change checkbox, the generator appends both the ! to the header and the BREAKING CHANGE: description footer in the correct format. This makes it straightforward to generate commit messages that drive automated changelog generation and version bumping tools like standard-version, semantic-release, and release-please.
The scope field is optional but strongly recommended for monorepos and larger codebases. Common scope values include component names (auth, api, ui), package names, or feature areas. The description field tracks character count (72-character limit shown) to keep the commit summary within the conventional limit — long summaries get truncated in many git log views. The body field allows multi-line text for explaining the motivation and context of a change, which is especially valuable when reviewing code history months later.
Key Features
- Eleven commit types: feat, fix, docs, style, refactor, test, chore, perf, ci, build, revert
- Optional scope field in parentheses — e.g. feat(auth): add OAuth2 login
- Description character counter (72-char limit display) to prevent overly long summaries
- Multi-line body textarea for detailed change context and motivation
- Breaking Change toggle: adds ! to header AND appends BREAKING CHANGE: footer
- Live preview in a formatted code block — see the final message update in real time
- One-click clipboard copy with visual confirmation (Copied! feedback)
- 100% client-side — no server requests, message never leaves your browser
Frequently Asked Questions
What is the Conventional Commits specification?
Conventional Commits is a commit message convention that provides a structured format: type(scope)!: description. It was created to make commit histories machine-readable so that tools can automatically determine version bumps (patch/minor/major) and generate changelogs. The specification is widely adopted by open-source projects and is supported natively by Angular, Vue, Nest.js, and many other frameworks.
What is the difference between feat and fix commit types?
feat (feature) is used when a commit introduces a new capability or behavior that end users can observe. fix is used when a commit corrects a bug or unintended behavior. The distinction matters for semantic versioning: feat triggers a minor version bump (e.g. 1.2.0 → 1.3.0), while fix triggers a patch bump (e.g. 1.2.0 → 1.2.1).
When should I use the scope field?
Use scope to identify the component, module, or area of the codebase affected by the change. Common values: auth, api, ui, database, config, docs, deps. Scope is optional but very useful in monorepos and large projects where multiple teams work on the same repository — it allows engineers to filter commit history by area using git log --oneline.
What counts as a Breaking Change?
A breaking change is any change that requires consumers of an API, CLI, or library to modify their existing code. Examples: removing a public function, changing a function signature, renaming an API endpoint, changing the structure of a configuration file. Mark the Breaking Change checkbox and describe what changed and how to migrate. This triggers a major version bump (e.g. 1.2.3 → 2.0.0).
Why is there a 72-character limit on the description?
The 72-character limit comes from the git log and GitHub pull request conventions. Git log --oneline truncates subjects longer than about 72 characters in most terminal widths. GitHub also wraps or truncates long commit subjects in PR commit lists and blame views. Keeping the subject short forces you to write a concise summary, with full details moved to the commit body.
What should go in the commit body?
The commit body should explain the motivation for the change, not just what changed. Write "Why was this necessary?" and "How does the new approach differ from the old one?" — the diff already shows what changed. For bug fixes, explain the root cause. For refactors, explain the design rationale. Good commit bodies are invaluable when debugging regressions months after a change was merged.
How do I use this commit message in the terminal?
Copy the generated message from the preview. In your terminal, after staging your changes with git add, run git commit — your default editor will open. Paste the message there. Alternatively, for single-line commits run git commit -m "feat(scope): description". For multi-line messages, use git commit (without -m) and write in the editor, or use git commit -m "subject" -m "body paragraph".
Which tools can automatically generate changelogs from Conventional Commits?
Several tools parse Conventional Commits to automate releases: standard-version (npm package), semantic-release (full CI/CD automation), release-please (GitHub Actions), and changesets (monorepo-focused). These tools read your commit history, determine the next semantic version, and generate a CHANGELOG.md — removing the need to maintain changelogs manually.