Git Commit Linter

What Makes a Good Git Commit Message?

Git commit messages are one of the most important yet overlooked parts of software development. A well-written commit message tells collaborators — and your future self — why a change was made, not just what changed. Good commit history makes code reviews faster, debugging easier, and changelogs automatic.

The Conventional Commits specification is a lightweight convention on top of commit messages. It follows the format type(scope): description, where type describes the kind of change (feat, fix, docs, etc.), scope optionally identifies what part of the codebase changed, and the description is a short imperative summary. This structured format enables automated changelog generation and semantic versioning.

Two foundational rules for subject lines are the 50/72 rule and imperative mood. The subject should ideally be 50 characters or fewer (and never exceed 72) so it renders cleanly in git log, GitHub, and email clients. Using imperative mood — "Add feature" not "Added feature" — matches the style of Git's own generated messages and reads as a command applied to the codebase.

How to Use This Tool

1. Paste or type your git commit message into the text area on the left.
2. The linter runs in real time — results appear immediately as you type.
3. Review your score (0–100) and the rules checklist on the right.
4. Green checkmarks mean a rule passes. Yellow warnings and red errors show what needs fixing, with a suggestion for each.

Common Use Cases

Frequently Asked Questions

What is the Conventional Commits specification? ▾

Conventional Commits is a lightweight convention for commit messages that follows the format: type(scope): description. The type indicates the kind of change (feat for features, fix for bug fixes, docs for documentation, etc.). The scope is optional and identifies the area of the codebase. This structured format enables tools to automatically generate changelogs and determine semantic version bumps.

Why should the subject line be under 72 characters? ▾

Many tools that display commit history — including git log --oneline, GitHub's commit list, and various email clients — start to truncate or wrap subject lines around 72 characters. This is a widely adopted convention, not a hard rule enforced by Git itself. The 50-character guideline is a further refinement: it is the point at which most interfaces start to feel crowded, and it forces you to be concise about what a commit does.

What is imperative mood in commit messages? ▾

Imperative mood means writing as if giving a command: "Add login page", "Fix null pointer exception", "Remove deprecated API". This is the convention Git itself uses in its auto-generated messages ("Merge branch", "Revert commit"). Writing in past tense — "Added login page" — is the most common mistake. A good test: the message should complete the sentence "If applied, this commit will... [your subject line]."

Should I always use Conventional Commits format? ▾

Conventional Commits is highly recommended for projects that use automated release tooling (semantic-release, standard-version, Release Please) or that want structured changelogs. For personal projects or teams that do not use these tools, it is still good practice — but the most important rules are a clear subject, imperative mood, and the 50/72 length guideline. Consistency within your team matters more than which exact convention you choose.

Can I use this as a pre-commit hook? ▾

This browser tool is for learning and checking messages interactively. For automated enforcement in your repository, use commitlint (npm package) with a husky pre-commit hook, or the commit-msg hook directly. You can configure commitlint with @commitlint/config-conventional to enforce the same Conventional Commits rules this tool checks.