Commitlint Explained

Commitlint is a tool that checks whether your Git commit messages follow a standard format. When you write a commit message (the note you leave when saving code changes), this tool validates that your message matches a consistent pattern. If your message doesn't fit the rules, commitlint rejects it and tells you what's wrong. This keeps all your team's commit messages organized and predictable.

The standard format commitlint enforces is called "conventional commits." A typical message looks like "fix(server): send cors headers" — you start with a type like "fix" or "feat," optionally specify what part of the code you changed in parentheses, and then describe the change. Common types include fix, feat, chore, docs, and test. You can customize which types are allowed and what other rules apply to your project.

To use it, you install commitlint as a development dependency (a tool only you need while building, not something your users need) and add a configuration file that says which rules to follow. Then you hook it into Git so that every time someone tries to commit code, Git automatically runs commitlint first. If the message is bad, the commit fails and the person has to rewrite it. This happens automatically through a tool called Husky, which watches Git events.

Teams use commitlint because consistent commit messages make it much easier to understand your project's history, generate release notes automatically, and find when bugs were introduced. If everyone writes "fix: login button not visible" instead of "oops fixed something," your entire team can read and search the history much faster. It's especially helpful for open-source projects or large teams where dozens of people commit code regularly.