Conventional Commits is a standardized commit message convention that provides a lightweight framework for creating explicit commit histories, enabling automated tooling for semantic versioning, changelog generation, and release automation. Combined with commit linting tools like commitlint, teams enforce consistent commit message formats at commit time through Git hooks, ensuring every commit follows the convention before it enters the repository. This structured approach transforms commit messages from arbitrary text into machine-readable data that drives automated workflows, making it essential knowledge that breaking changes are explicitly marked with BREAKING CHANGE: in the footer—tooling reads this token to trigger major version bumps automatically.
What This Cheat Sheet Covers
This topic spans 20 focused tables and 140 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Core Commit Message Format
| Component | Example | Description |
|---|---|---|
feat(api): add user authentication endpoint | Commit message consists of type, optional scope in parentheses, colon, and subject—this is the minimum required format; body and footer are optional. | |
feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert | Mandatory field describing the category of change; feat triggers minor release, fix triggers patch release; other types have no version impact unless flagged as breaking. | |
feat(parser): add CSV supportfix(auth/login): resolve token expiry | Optional field identifying the affected component or module; can be nested with / delimiter; helps filter commits by area; no standard list—defined per project. | |
add user authentication endpoint | Short imperative description of the change; use present tense ("add" not "added"); no period at end; typically 50 characters or fewer; lowercase preferred. |