Git Commit Message Linter

Conventional Commits is a specification for structuring commit messages: <type>(<scope>): <description>. Common types are feat (new feature), fix (bug fix), docs, style, refactor, test, and chore. This format enables automated changelog generation, semantic versioning, and makes git history scannable. It's used by Angular, Vue, and many major open source projects.

feat is for commits that add a new feature visible to users or consumers of the library. fix is for commits that fix a bug. In semantic versioning, feat triggers a minor version bump (1.0.0 → 1.1.0) and fix triggers a patch bump (1.0.0 → 1.0.1). A BREAKING CHANGE footer triggers a major bump (1.0.0 → 2.0.0).

The Conventional Commits specification recommends lowercase for the description. The rationale: consistency makes grep and automated tooling simpler. Most linters (commitlint) default to enforcing lowercase. However, many teams use capitalized descriptions — the important thing is team consistency. This linter flags both conventions.

The subject line (first line) should be 50 characters or less for git log readability, with a hard limit of 72 characters. GitHub truncates subjects longer than 72 characters in list views. If you need more context, add a blank line after the subject followed by a body paragraph. The body should wrap at 72 characters.

A BREAKING CHANGE is a change that is not backwards-compatible — it requires users to update their code. In Conventional Commits, you signal this with BREAKING CHANGE: description in the commit footer, or by adding a ! after the type: feat!: remove deprecated API. Either triggers a major version bump in semantic versioning.