Git Commit Message Writer: Professional Commits Every Time
Clear commit messages make your git history readable and useful. This tool generates conventional commit messages that follow industry best practices.
Generate a precise, well-structured git commit message following the Conventional Commits specification that clearly communicates what changed and why.
COMMIT MESSAGE GUIDELINES:
1. Determine the Commit Type
- feat: A new feature visible to users or downstream consumers
- fix: A bug fix (reference the bug or symptom being resolved)
- docs: Documentation-only changes
- style: Formatting, whitespace, semicolons (no logic change)
- refactor: Code restructuring with no behavior change
- perf: Performance improvement
- test: Adding or correcting tests
- build: Changes to build system or dependencies
- ci: Changes to CI configuration or scripts
- chore: Maintenance tasks that do not fit other types
2. Determine the Scope
- Identify the module, component, or area affected (e.g., auth, api, db, ui, payments)
- Use lowercase, hyphenated names
- Omit scope only if the change is truly cross-cutting
3. Write the Subject Line
- Use imperative mood ("add" not "added" or "adds")
- Do not capitalize the first letter after the colon
- Do not end with a period
- Keep under 72 characters total (including type and scope)
- Be specific: "fix null pointer in user lookup" not "fix bug"
4. Write the Body (when changes are non-trivial)
- Explain WHAT changed and WHY, not HOW (the diff shows how)
- Reference the problem or motivation that led to this change
- If there are multiple logical changes, consider whether this should be multiple commits
5. Write the Footer (when applicable)
- BREAKING CHANGE: description (if the change breaks backward compatibility)
- Refs: #issue-number or ticket ID
- Co-authored-by: if applicable
OUTPUT CONSTRAINTS:
- Always output the commit message in a copy-paste-ready code block
- If the changes described suggest multiple unrelated modifications, recommend splitting into separate commits and provide a message for each
- Subject line must be under 72 characters
- Body lines should wrap at 72 characters
- If the changes are trivial (typo fix, single-line change), a subject-only message is fine; do not add an unnecessary body
FORMAT:
```
type(scope): subject line
[Body paragraph explaining what and why, if non-trivial]
[Footer with references or breaking changes, if applicable]
```
---
MY INFO:
Changes Made: (required - describe what you changed and why)
Issue/Ticket Number: (optional)
Breaking Changes: (optional - describe any backward-incompatible changes)
Conventional Commits Format
<type>(<scope>): <description>
[optional body]
[optional footer]
Commit Types
- feat: New feature
- fix: Bug fix
- docs: Documentation changes
- style: Code style (formatting, semicolons)
- refactor: Code refactoring
- test: Adding tests
- chore: Maintenance tasks
Good vs Bad Commits
Bad: "fixed stuff" Good: "fix(auth): resolve token expiration issue on refresh"
Benefits of Good Commit Messages
- Searchable git history
- Automatic changelog generation
- Clear code review context
- Easy rollback identification
Write commits that tell a story about your codebase evolution.