In a Conventional Commits message, what do the type, scope, and trailing ! mean?

## The grammar A Conventional Commits message looks like this: ``` feat(parser): support trailing commas in arrays The tokenizer rejected a comma before a closing bracket, which broke round-tripping of configs written by the editor. Refs: PROJ-142 ``` Structurally it is an ordinary Git commit message — subject, blank line, body, footers. The convention only constrains the shape of the subject line and the footer vocabulary. Git itself knows nothing about it; the value comes entirely from tools and humans agreeing to read it. The subject is `<type>[(<scope>)][!]: <description>`. ## Type The type is a lowercase noun classifying the *kind* of change. The specification pins down only two: `feat` for a new feature and `fix` for a bug fix. Everything else — `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore` — is convention inherited from the Angular guidelines and is a team choice, not a rule. The important discipline is that the type describes the change's nature, not the file it touched: editing a test file as part of a bug fix is still `fix`. ## Scope The scope is an optional parenthesised noun naming the part of the codebase affected: `fix(auth):`, `feat(api):`. The specification does not define a vocabulary, so a team picks one — module names, package names, or service names. Two failure modes are common: scopes so fine-grained that they mirror file paths and add nothing, and a free-for-all where the same area appears under three spellings. Both are avoidable with a short agreed list. ## The breaking-change marker A `!` placed immediately before the colon — `feat(api)!: drop the v1 response envelope` — declares that the change breaks consumers. The alternative, and the one that lets you explain yourself, is a footer: a line beginning `BREAKING CHANGE: ` followed by a description of what broke and what to do about it. Using both is fine and common: the `!` is visible in `git log --oneline`, the footer carries the detail. ## Why bother The payoff is that a commit history becomes structured data: - **Version inference.** The specification maps `fix` to a patch release, `feat` to a minor release, and a breaking marker to a major release, in semantic-versioning terms. A release process can compute the next version from the commits since the last tag rather than from someone's memory. - **Changelog generation.** Grouping by type gives "Features" and "Bug Fixes" sections without anyone maintaining a file by hand. - **Human scanning.** `git log --oneline` becomes filterable by eye, and `git log --grep '^fix'` becomes meaningful. ## The costs The convention is only as good as its worst commit. A single `feat:` on a bug fix mislabels a release; a `chore:` on a breaking change silently ships an incompatible version. So teams that rely on the mapping enforce it — typically a `commit-msg` hook that rejects a non-conforming subject, plus a check in CI so the rule survives a developer who has not installed hooks. Enforcement has its own cost: it blocks commits at an annoying moment and tempts people into a habitual `chore: update` that satisfies the parser and tells the reader nothing. There is also a scope mismatch worth naming: the convention classifies commits, but releases are usually cut from merged branches. If your history is squashed or merged in ways that lose individual subjects, the mapping operates on whatever survives, which is a decision your merge strategy makes, not the convention. ## When it is worth adopting It earns its keep where automated versioning or generated changelogs are genuinely wanted — published libraries, versioned APIs, anything with external consumers reading release notes. In an internal application deployed continuously from the mainline, the machine-readability may buy nothing, and the honest answer in an interview is that the convention is a means to an end rather than a virtue in itself. ## Interview framing Give the grammar precisely, name `feat` and `fix` as the only specified types, explain the `!` and the `BREAKING CHANGE:` footer as equivalents, and then say what the structure is *for*. Candidates who recite the type list but cannot say why the type matters have learned the form and missed the function.