Git Commit Message Linter
About Commit Message Linter
The Commit Message Linter validates your Git commit messages against the Conventional Commits specification. This standard helps teams maintain consistent, readable commit history that can be automatically processed for changelog generation, semantic versioning, and more.
Why Use Conventional Commits?
- Automatic changelogs: Generate CHANGELOG.md files automatically from commit history
- Semantic versioning: Determine version bumps (major, minor, patch) based on commit types
- Better navigation: Quickly find specific changes by filtering commits by type
- Clearer history: Understand the purpose of each commit at a glance
- Team consistency: Establish a standard format across all team members
Conventional Commits Format
The basic format is:
<type>(<scope>): <description>
[optional body]
[optional footer(s)]
Commit Types
feat
Feature: A new feature for the user (triggers MINOR version bump)
Example:
Example:
feat(auth): add two-factor authentication
fix
Bug Fix: A bug fix (triggers PATCH version bump)
Example:
Example:
fix(parser): handle null values correctly
docs
Documentation: Documentation only changes
Example:
Example:
docs: update API documentation
style
Style: Changes that don't affect code meaning (whitespace, formatting)
Example:
Example:
style: format code with prettier
refactor
Refactor: Code change that neither fixes a bug nor adds a feature
Example:
Example:
refactor(database): extract query logic to separate class
perf
Performance: Code change that improves performance
Example:
Example:
perf: reduce database queries in user dashboard
test
Test: Adding or correcting tests
Example:
Example:
test: add unit tests for authentication service
build
Build: Changes to build system or dependencies
Example:
Example:
build: upgrade webpack to version 5
ci
CI/CD: Changes to CI configuration files
Example:
Example:
ci: add GitHub Actions workflow for testing
chore
Chore: Other changes that don't modify src or test files
Example:
Example:
chore: update .gitignore
revert
Revert: Reverts a previous commit
Example:
Example:
revert: revert "feat: add experimental feature"
Breaking Changes
To indicate a breaking change (triggers MAJOR version bump), use either:
- Exclamation mark after type/scope:
feat!: remove deprecated API - Footer with BREAKING CHANGE:
BREAKING CHANGE: API endpoints now require authentication
Scope (Optional)
The scope provides additional context about which part of the codebase changed:
feat(auth): add login functionality- changes to authentication modulefix(api): handle rate limit errors- changes to API layerdocs(readme): add installation instructions- changes to README
Best Practices
- Keep header under 72 characters: Ensures readability in git log and GitHub
- Use lowercase for description: Start with lowercase letter after the colon
- Use imperative mood: "add feature" not "added feature" or "adds feature"
- Don't end with a period: The header should not end with punctuation
- Separate header from body: Use a blank line between header and body
- Wrap body at 72 characters: For better readability in various tools
- Use body to explain "why": The header says "what", the body should explain "why"
- Reference issues: Use footer for issue references like "Closes #123"
Good Examples
feat(api): add pagination to user list endpoint
Implement cursor-based pagination for better performance
with large datasets. This allows clients to fetch users
in smaller batches.
Closes #456
fix: prevent crash when config file is missing
Check if config file exists before attempting to read.
Fall back to default configuration if file is not found.
docs: add contributing guidelines
Create CONTRIBUTING.md with instructions for:
- Setting up development environment
- Running tests
- Submitting pull requests
Bad Examples
❌ Updated some files
(Missing type, too vague)
❌ Fix bug
(Too vague, no context)
❌ feat: Added new feature for users to login with social media accounts.
(Too long, should use body for details)
❌ FEAT: Add feature
(Type should be lowercase)
Integration with Tools
Conventional commits work seamlessly with:
- Commitlint: Automate validation in pre-commit hooks
- Standard Version: Automatic versioning and CHANGELOG generation
- Semantic Release: Fully automated package publishing
- Conventional Changelog: Generate changelogs from git metadata
Related Tools
- Changelog Generator - Generate changelogs from commits
- Semantic Version Calculator - Calculate version bumps
- Git Command Generator - Build Git commands
- TODO Extractor - Extract TODO comments
- Word Counter - Count words in text