Commit Message Generator
Generate clear, conventional commit messages following best practices.
Instructions
- •Run
git diff --stagedto see staged changes - •Analyze the changes to understand:
- •What was modified (files, functions, components)
- •Why the change was made (purpose, goal)
- •Impact of the change
- •Generate a commit message with:
- •Type: feat, fix, docs, style, refactor, test, chore
- •Scope: affected component/module (optional)
- •Summary: imperative mood, max 50 characters
- •Body: detailed explanation (wrap at 72 chars)
- •Footer: breaking changes, issue references
Format
code
<type>(<scope>): <summary> <body> <footer>
Examples
Example 1: Feature
code
feat(auth): add JWT token refresh mechanism Implement automatic token refresh to improve user experience by preventing unexpected logouts. The refresh token is stored securely in httpOnly cookies. Closes #123
Example 2: Bug fix
code
fix(api): handle null values in user profile endpoint Add validation to prevent crashes when optional fields are null. This fixes a bug where the API would return 500 errors for users with incomplete profiles. Fixes #456
Example 3: Documentation
code
docs(readme): update installation instructions Add missing steps for setting up environment variables and clarify the database migration process.
Best Practices
- •Use present tense ("add feature" not "added feature")
- •Don't end summary with a period
- •Explain what and why, not how
- •Reference issues/tickets when applicable
- •Keep summary under 50 characters
- •Wrap body at 72 characters
- •Use imperative mood ("fix" not "fixes" or "fixed")
Commit Types
- •feat: New feature
- •fix: Bug fix
- •docs: Documentation changes
- •style: Code style changes (formatting, no logic change)
- •refactor: Code refactoring (no feature or bug fix)
- •perf: Performance improvements
- •test: Adding or updating tests
- •chore: Maintenance tasks (dependencies, config)
- •ci: CI/CD changes
- •build: Build system changes