Setting the file. One moment.
Subchapter 194.1
references/commit-classification.mdMarkdown3 KBView on GitHub
Role in the workflow: Commit messages are a secondary signal. The code diff is always read first and treated as ground truth. Use these heuristics to add intent and context on top of what the diff already shows — not to replace it. When a commit message contradicts the diff, trust the diff.
When reading git log output, map each commit to one of the categories below.
Repos that follow Conventional Commits (https://www.conventionalcommits.org/ (opens in a new tab)) will
have explicit prefixes — use them directly. For freeform commit messages, use the
heuristics.
| Prefix | Category |
|---|---|
feat: / feat(scope): | feat |
fix: / fix(scope): | fix |
perf: | perf |
refactor: | refactor |
docs: | docs |
chore: | chore |
test: / tests: | test |
ci: | chore |
build: | chore |
style: | chore |
revert: | depends on what was reverted |
BREAKING CHANGE in footer or ! after type (e.g. feat!:) | breaking |
Breaking:
Feat (new feature):
Fix:
Perf:
Refactor:
Docs:
Chore:
Test:
Merge commits (e.g., Merge pull request #42) are usually noise. Look at the PR title
or the commits inside the merge. If the PR title follows Conventional Commits, use that.
Default to PATCH if the commit looks like maintenance. Escalate to MINOR if there’s any mention of new functionality. Escalate to MAJOR only with explicit evidence of a breaking change — don’t guess at breaking.
| Category | Changelog section |
|---|---|
breaking + new behavior | Changed |
breaking + removal | Removed |
feat | Added |
fix, perf | Fixed |
security | Security |
refactor, docs, chore, test | Omit (unless user-visible) |
User-visible refactor example: Extracting a previously internal helper into a new public export → treat as Added, not Refactor.