conventional-changelog/commitlint

📈 Trending★ 18,535TypeScriptAudience · developerComplexity · 2/5ActiveLicenseSetup · easy

Mindmap

mindmap
  root((commitlint))
    What it does
      Checks commit messages
      Enforces format rules
      Blocks bad commits
    How it works
      Git hooks locally
      CI pipeline checks
      Config files
    Commit format
      Type field
      Optional scope
      Short subject
    Use cases
      Team consistency
      Auto changelog gen
      History readability
    Configuration
      Shared configs
      Custom rules
      package.json setup

mindmap root((commitlint)) What it does Checks commit messages Enforces format rules Blocks bad commits How it works Git hooks locally CI pipeline checks Config files Commit format Type field Optional scope Short subject Use cases Team consistency Auto changelog gen History readability Configuration Shared configs Custom rules package.json setup

Things people build with this

USE CASE 1

Enforce consistent commit message format across a team so the git history is readable and searchable.

USE CASE 2

Automatically generate changelogs from commit messages by parsing their standardized structure.

USE CASE 3

Prevent developers from committing messages that don't follow your project's conventions.

USE CASE 4

Set up shared commit rules across multiple repositories using pre-built configurations.

Tech stack

TypeScriptNode.jsGit hooks

Getting it running

Difficulty · easy Time to first run · 5min

Use freely for any purpose, including commercial use, as long as you keep the copyright notice.

In plain English

commitlint is a tool that checks whether git commit messages follow a consistent format before they are accepted. A commit message is the note a developer writes to describe what changed in a set of code edits. When many developers contribute to the same project, inconsistent commit messages make it hard to read the history or automatically generate changelogs. The conventional commit format commitlint enforces looks like: type(scope): subject, for example, fix(server): send cors headers or feat(blog): add comment section. The type describes the nature of the change (fix, feat, chore, docs, test, and others), the optional scope narrows down which part of the codebase was affected, and the subject is a short description. commitlint checks that messages match this pattern and flags anything that doesn't. It is typically configured to run automatically as a git hook, meaning it checks your message every time you commit locally, or as part of a continuous integration pipeline so that messages are validated whenever code is pushed to a shared repository. Configuration is loaded from files like .commitlintrc or a commitlint field in package.json. A number of pre-built shared configurations are available to extend, covering different convention styles. The library is MIT-licensed and maintained as a monorepo, a single repository containing multiple related packages.

Copy-paste prompts

Prompt 1

How do I set up commitlint to check commit messages in my project before they're saved?

Prompt 2

Show me how to configure commitlint to enforce 'type(scope): subject' format with custom rules.

Prompt 3

What's the conventional commit format and how does commitlint validate it?

Prompt 4

How can I use commitlint in a CI pipeline to reject pull requests with bad commit messages?

Prompt 5

How do I extend a shared commitlint config in my project's package.json?

Open on GitHub → Explain another repo

Generated 2026-05-18 · Model: sonnet-4-6 · Verify against the repo before relying on details.