Git Commit Message Generator
Generate properly formatted commit messages following the Conventional Commits specification.
Use imperative mood (e.g., "add" not "added" or "adds")
Provide additional context, explain what and why vs. how
BREAKING CHANGE: description or Closes #123, Fixes #456. Auto-detects issue numbers.
Conventional Commits Format
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]Types
- feat: A new feature
- fix: A bug fix
- docs: Documentation only changes
- style: Code style changes (formatting, missing semicolons, etc.)
- refactor: Code refactoring without changing functionality
- perf: Performance improvements
- test: Adding or updating tests
- build: Changes to build system or dependencies
- ci: Changes to CI/CD configuration
- chore: Other changes that don't modify src or test files
- revert: Revert a previous commit
Generate Proper Git Commit Messages with Conventional Commits
Create well-structured, standardized commit messages that follow the Conventional Commits specification. This tool helps developers maintain consistent commit history, improve code review efficiency, and enable automated versioning and changelog generation.
Why Use Conventional Commits?
- Consistency: Standardized format makes it easier to understand commit history at a glance.
- Automation: Enables automated version bumping based on commit types (feat = minor, fix = patch, BREAKING CHANGE = major).
- Changelog Generation: Tools can automatically generate changelogs from commit messages.
- Better Code Reviews: Clear commit messages help reviewers understand the purpose of changes quickly.
- Searchability: Easy to search commit history by type (e.g., find all bug fixes).
Commit Message Structure
A conventional commit message follows this format:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]Common Commit Types
- feat: A new feature that adds functionality.
- fix: A bug fix that resolves an issue.
- docs: Documentation-only changes (README, comments, etc.).
- style: Code style changes that don't affect functionality (formatting, whitespace).
- refactor: Code restructuring without changing behavior.
- perf: Performance optimizations and improvements.
- test: Adding or modifying tests.
- build: Changes to build system, dependencies, or configuration files.
- ci: Changes to CI/CD configuration (GitHub Actions, Jenkins, etc.).
- chore: Maintenance tasks that don't modify source or test files.
- revert: Reverting a previous commit.
Best Practices
- Use imperative mood: Write "add feature" not "added feature" or "adds feature".
- Keep it concise: Description should be 50 characters or less when possible.
- Add scope when relevant: Specify the component or module affected (e.g., "auth", "api", "ui").
- Explain the why: Use the body to explain what and why, not how (the code shows how).
- Reference issues: Use footer to close issues (e.g., "Closes #123") or indicate breaking changes.
- Breaking changes: Use "BREAKING CHANGE:" in footer for changes that break backward compatibility.
Example Commit Messages
feat(auth): add OAuth2 login support
Implement Google and GitHub OAuth2 authentication.
Allows users to sign in with external accounts.
Closes #123
---
fix(api): resolve null pointer exception in user endpoint
Handle null user data gracefully and return proper error response.
Fixes #456
---
docs(readme): update installation instructions
Add Node.js version requirement and Docker setup steps.
---
refactor(utils): extract validation logic into separate module
Improve code organization and reusability.Integration with Tools
Conventional commits work seamlessly with popular tools:
- Semantic Versioning: Automatically determine version bumps based on commit types.
- Changelog Generators: Tools like
standard-versionandsemantic-releasegenerate changelogs automatically. - Git Hooks: Use commit-msg hooks to validate commit message format.
- CI/CD: Automate releases based on commit message patterns.