search

Found

info Overview

Check commit messages against 8 Conventional Commits rules: type, 50/72-char subject, imperative mood, and footer — color-coded with a copyable report.

📘 How to Use

  1. Paste your commit message into the input box
  2. Write the subject, body, and footer from line one
  3. Review the pass/fail status of all 8 rules

Commit Message Validator

0 / 8
Copied

grid_view Related

Article

Commit Message Validator｜Lint Conventional Commits Against 8 Rules

Paste a commit message and see whether it follows the Conventional Commits format across 8 rules. Subject format, length, imperative mood, body wrapping, breaking-change markers, and footer tokens are laid out side by side, each marked pass, warn, or fail.

💡 About this tool

If you have ever opened a pull request and watched the reviewer reply "please rewrite the commit message," you know how fuzzy commit conventions can feel. Should the subject start with feat:? How long is too long? Does the body need a blank line above it? Teams write these rules into a CONTRIBUTING file and then forget half of them by the next sprint. This tool turns that document into a working checklist: paste the message, read the eight verdicts, fix what is red.

The 8 rules are: R1 subject format (type(scope): subject), R2 subject length (50 recommended, 72 required), R3 no trailing period, R4 imperative mood, R5 blank line between subject and body, R6 body lines wrapped at 72 characters, R7 breaking-change consistency (! matches BREAKING CHANGE:), and R8 footer token format (Refs:, Closes #N). The verdicts copy out as a plain-text audit report you can paste into a review comment or a team style guide.

🧐 Frequently Asked Questions

Q. What is Conventional Commits? It is a lightweight convention that prefixes commit subjects with a type such as feat, fix, or docs so tooling can derive changelogs and semantic version bumps from your history. It is widely used across open-source projects.

Q. Why 50 and 72 characters? The 50-character target keeps subjects scannable in git log and on GitHub; 72 is the hard ceiling before terminal wrapping truncates the line. This tool warns past 50 and fails past 72, so you see both thresholds.

Q. How does the imperative-mood check work? R4 is a heuristic: it flags a first body word ending in -ed or -ing (for example "Added" or "Adding") and suggests "Add." It is advisory, not absolute, and shows a warning rather than a hard failure.

Q. Is the scope required? No. feat: ... passes R1 just as well as feat(parser): .... The scope in parentheses is optional and only constrained to lowercase letters, digits, and hyphens.

Q. How do I mark a breaking change? Add a ! after the type (feat!:) or a BREAKING CHANGE: line in the body. R7 confirms the two stay in sync and warns if only one is present.

📚 Why 72 Columns Still Rules Your Commits

The "50/72" numbers are a fossil from the terminal era. Early Unix terminals were 80 columns wide, and git log indents body text by four spaces, leaving 72 usable columns before a line wraps awkwardly. Linus Torvalds and the Git documentation cemented this as a community habit long before Conventional Commits existed. What the spec added on top was structure: by turning a free-form sentence into a typed contract, it let release tools read human prose. That is why a one-line lint like this matters more than it looks — a malformed subject does not just look untidy, it can silently break an automated release pipeline that parses your history.