Conventional Commit Messages Checker
Check Conventional Commit headers or full messages against repository rules and see each valid message’s release impact before publishing.| # | Header | Type | Scope | Subject | Status | Impact | Copy |
|---|---|---|---|---|---|---|---|
| {{ row.index }} | {{ row.header }} | {{ row.type }} | {{ row.scope }} | {{ row.subject }} | {{ row.status }} | {{ row.impact }} |
| Message | Severity | Rule | Finding | Suggested fix | Copy |
|---|---|---|---|---|---|
| #{{ row.message_index }} | {{ row.severity }} | {{ row.rule }} | {{ row.detail }} | {{ row.fix }} | |
| No findings under the active policy. | |||||
A commit message becomes release evidence when its first line states what changed in a predictable form. Vague headers such as updates may be clear to their author today, but they give reviewers, changelog generators, and versioning automation little information about defects, features, or compatibility.
Conventional Commits place a compact structure on that first line. A type comes first, an optional scope narrows the affected area, an optional exclamation mark identifies a breaking change, and a subject follows a colon and space. Bodies may explain the work, while footers can carry breaking-change detail or other trailers.
| Part | Example | Meaning |
|---|---|---|
| Type | feat | The category of change. Repositories often maintain an allowed list. |
| Scope | (api) | An optional area affected by the change. |
| Breaking marker | ! | A visible signal that existing consumers may need to adapt. |
| Separator | : | A colon followed by one space before the subject. |
| Subject | add retry envelope | A concise description of the change. |
The convention connects naturally with Semantic Versioning: a valid breaking change points toward a major release, feat toward minor, and fix toward patch. Other types do not acquire a version meaning from the base specification. Teams commonly add lint rules for allowed types, case, length, punctuation, and generated Git lines.
Format cannot prove intent. A perfectly shaped fix may hide a breaking API change, while a poor header may describe harmless documentation. Commit-message checks make history easier to process; the diff, public API, migration notes, and repository release policy still decide what must ship.
The costly mistake is allowing message policy and release automation to drift apart. If a hook accepts one type list while the release job interprets another, passing commits can disappear from notes or trigger the wrong version. Use the same profile at authoring, continuous integration, and release time.
How to Use This Tool:
Match the checker settings to the repository gate that will consume the messages.
- Paste commit messages, then choose Message parsing. Use one header per line for a subject list; use full messages separated by a line containing
---when bodies or breaking footers matter. - Select Rule profile. The recommended profile applies common lint rules, strict adds paired breaking markers and kebab-style scope segments, structure-only follows the base header shape, and custom uses your type list.
- Open the advanced settings only when the repository differs from the selected profile. Extra types, header length, scope case, breaking-marker policy, final periods, and merge or autosquash lines can all change the result.
- Correct any input error, then read Rule findings before Release impact. A custom profile needs at least one type, the header limit must be 0 to 140, and the source may not exceed 1 MiB. Errors make a message invalid; warnings preserve its release mapping.
Interpreting Results:
Pass means the active rules accepted the message. Warn means the header parsed but a warning rule found case, length, or punctuation that needs review. Fail means at least one error remains, so release impact is Invalid. Generated merge or autosquash lines are Ignored unless they are explicitly included.
Major, Minor, Patch, and None are message-derived cues, not a final version calculation. Compare the highest valid impact with the actual code change and the release process. A batch can pass every formatting rule and still be versioned incorrectly when the author chose the wrong type or omitted a breaking marker.
Commit text is checked in the browser, but copied reports can expose unreleased feature names, customer references, issue numbers, or internal architecture. The result does not inspect a Git diff, run repository hooks, or read release configuration, so reproduce the chosen profile in the real commit or continuous-integration gate.
Technical Details:
The first non-empty line of each message is the candidate header. Auto detect chooses full-message blocks when it finds a line made only of three or more dashes; otherwise each non-empty line is treated as a separate header. Full blocks retain later text for breaking-footer checks.
Rule Core:
A header must follow type(scope)!: subject, with the scope and exclamation mark optional. The type begins with a letter and may contain letters, digits, or hyphens. Scope text may not contain parentheses or a line break, and the subject must contain text after the exact colon-space separator.
| Profile | Type and scope policy | Other defaults |
|---|---|---|
| Commitlint recommended | Lower-case type from the standard 11-type list plus additional types; lower-case scope. | Header at most 72 characters, no final subject period, bang or footer may mark breaking change. |
| Strict release gate | The same type list; scope uses lower-case segments separated by hyphen, slash, backslash, or comma. | Header at most 72 characters, no final period, and the bang and footer must appear together. |
| Structure only | Any syntactically valid type and any scope case. | No header-length or final-period rule; bang or footer marks a breaking change. |
| Custom type list | Lower-case type from the supplied custom and additional lists; lower-case scope. | Uses the recommended length, punctuation, and breaking defaults unless overridden. |
Leading or trailing header whitespace, malformed structure, disallowed or non-lower-case types, an empty subject, malformed breaking footers, and failed strict pairing are errors. Scope case, headers over the active nonzero limit, and a final subject period under lint-style policy are warnings.
Transformation Core:
| Condition | Release impact | Priority |
|---|---|---|
| The generated-line policy skips the header. | Ignored | Applied before validation. |
| Any error-level finding remains. | Invalid | Applied before type mapping. |
| A valid bang or uppercase breaking footer is present. | Major | Overrides every type. |
The valid type is feat. | Minor | Used when no breaking marker exists. |
The valid type is fix or perf. | Patch | Used when no breaking marker exists. |
| Any other valid type. | None | No release bump is inferred here. |
A valid footer begins with uppercase BREAKING CHANGE: or BREAKING-CHANGE: and includes detail on the same line. A lowercase label or an empty description is an error. The strict paired policy rejects a bang without that footer and a footer without the bang.
By default, lines beginning with Git merge wording or fixup!, squash!, or amend! are omitted from checked counts. Turning on Check merge and autosquash lines sends them through the same header rules instead.
Worked Examples:
Breaking performance change:
A full block headed perf(search)!: replace fuzzy index with BREAKING CHANGE: rebuild the search index before startup passes strict marker pairing and maps to Major. Removing either marker creates an error under the strict profile, so the impact becomes Invalid rather than Major.
Valid header with a warning:
feat(api): add retry envelope. parses under the recommended profile but warns because the subject ends with a period. Warnings do not invalidate the message, so its release impact remains Minor unless the repository treats that warning as a separate gate failure.
References:
- Conventional Commits 1.0.0, Conventional Commits.
- Rules reference, Commitlint.
- Semantic Versioning 2.0.0, Semantic Versioning.
- How to view Git commit history, Simplified Guide.