Git Commit Message Linter
Validate commit messages against the Conventional Commits specification. Checks type, scope, subject length, body format and breaking change markers.
What is the Git Commit Message Linter?
The Git Commit Message Linter validates commit messages against the Conventional Commits specification — the widely adopted standard that defines a structured format for git commit messages. It checks the type prefix, optional scope, subject line length, case convention, body formatting, and the presence of breaking change markers in real time as you type. For DevOps and platform engineering teams, consistent commit messages are the foundation of automated release workflows and meaningful git history.
Without a consistent commit convention, git history becomes a free-form collection of messages like "fix bug", "update stuff", and "WIP" that provide no structured information for tooling. The Conventional Commits format solves this by requiring every commit to declare its intent — feat for a new capability, fix for a bug correction, ci for pipeline changes — which enables downstream automation to parse, group, and act on commit history without human intervention.
When to Use This Tool
- Before pushing a feature branch: Verify each commit message is valid before opening a pull request to avoid blocking a commitlint CI check.
- Onboarding new team members: Use the quick-type chips and live feedback to teach the Conventional Commits format interactively without requiring local tooling setup.
- Pre-commit hook authoring: Test exact message formats to confirm they will pass commitlint rules before encoding those rules in a Husky or lefthook configuration.
- Semantic release preparation: Validate that your
featandfixcommits are correctly formatted before running semantic-release to ensure the version bump will be correct.
How It Works
The linter parses the commit message header using a regular expression that extracts the type, optional scope, breaking-change marker (!), and subject. It then checks each component against the Conventional Commits v1.0 specification: the type must be one of the eleven recognized values, the subject must be non-empty and ideally under 72 characters, the first letter should be lowercase, and there should be no trailing period. Breaking changes are detected either by the ! suffix after the scope or by a BREAKING CHANGE: footer token in the commit body.
Frequently Asked Questions
What is the Conventional Commits format?
Conventional Commits is a specification for writing structured git commit messages in the format type(scope): subject. The type declares what kind of change the commit makes: feat for a new feature, fix for a bug fix, docs for documentation changes, style for formatting-only changes, refactor for code restructuring without behavioral change, perf for performance improvements, test for test additions or fixes, build for build system changes, ci for CI/CD pipeline changes, chore for maintenance tasks, and revert for reverting a previous commit. The scope is an optional noun in parentheses identifying the section of the codebase affected, and the subject is a short imperative description of the change.
Why should I use Conventional Commits?
Conventional Commits enables a wide range of automation that is impossible with free-form commit messages. Tools like semantic-release and standard-version parse your commit history to automatically determine the next semantic version number — a feat commit triggers a MINOR bump, a fix triggers a PATCH bump, and any breaking change triggers a MAJOR bump. The same parse generates a structured CHANGELOG.md grouped by change type. Teams using Conventional Commits spend significantly less time writing release notes, reviewing what changed between versions, or deciding how to bump version numbers. Pre-commit hooks with commitlint enforce the standard locally so non-conformant messages never reach the remote repository.
How do I enforce Conventional Commits in a CI pipeline?
The most common approach is to install commitlint (npm install --save-dev @commitlint/cli @commitlint/config-conventional) and add a Husky pre-commit hook that runs the linter before every local commit. In CI, you can add a pipeline step that runs commitlint --from origin/main to check every commit on the feature branch against the conventional commits ruleset, blocking the merge if any commit fails. GitHub Actions supports this via the wagoid/commitlint-action marketplace action, and GitLab CI can run the same npm command as a pipeline job. For teams that want to enforce conventions without adding Node.js dependencies, some git hosting platforms offer built-in commit message pattern matching as a branch protection rule.