About Commit Message Validator

Validate commit messages against conventional and imperative style guidelines. Part of the DevTools Surf developer suite. Browse more tools in the Developer Utilities collection.

Use Cases

• Validate commit messages in a pre-commit git hook before allowing the commit
• Audit a PR's commit history for conventional commit compliance before merging
• Train new team members on the project's commit message standards
• Check commit messages before running semantic-release for automated version bumping

Tips

• Select Conventional Commits or Angular commit convention — the validator applies the appropriate type list and scope format for each
• The subject line length is checked against the 72-character limit; this prevents message truncation in GitHub PR and terminal git log views
• Use the 'batch validate' mode to check a list of commit messages from a git log output before submitting a PR or creating a release

Fun Facts

• The Angular commit message convention, which became the basis for Conventional Commits, was first published in 2014 as part of AngularJS's contribution guidelines. It has since been adopted by tens of thousands of open-source projects.
• Tim Pope's 'A Note About Git Commit Messages' (2008) established the 50/72 rule: subject lines under 50 characters, body lines wrapped at 72. It remains the most cited single-page reference for commit message style, with millions of views.
• Linus Torvalds, creator of Git, has strong opinions on commit messages. Linux kernel contributions are routinely rejected for poor commit messages — the kernel's documented commit format is one of the most detailed in open source.

FAQ

What is a conventional commit?

A commit message following the format: type(scope): subject — e.g., feat(auth): add OAuth2 login. Types include feat, fix, docs, style, refactor, test, chore. BREAKING CHANGE in the body/footer triggers a MAJOR semver bump.

Why enforce commit message format?

Structured commit messages enable automated changelog generation, semantic versioning, and release notes. They also make git blame, bisect, and log much more useful for debugging — a 3-month-old commit with a clear message saves hours.

Should I squash commits before merging?

Squashing (combining multiple commits into one) keeps the main branch history clean. Merge without squashing preserves granular history. GitHub's 'Squash and Merge' option is the most common approach — it produces one clean commit per PR.