Commit Messages
3 exercises — rewrite bad commit messages, pick the right type and scope, and learn what makes a commit history searchable and professional.
0 / 3 completed
Conventional Commits format:
type(scope): short description - feat: new feature (triggers MINOR semver bump)
- fix: bug fix (triggers PATCH semver bump)
- docs: documentation changes only
- refactor: code restructured, no feature/bug change
- chore: build scripts, deps, tooling — no production code
- Rules: imperative mood · under 72 chars · no period at end · present tense
1 / 3
A developer pushes this commit message to the main branch:
"stuff"
Which rewrite best follows the Conventional Commits format: type(scope): short description?
Option B is correct. It follows Conventional Commits exactly:
fix (type) + (checkout) (scope) + imperative short description explaining what and why in under 72 characters. Option A is multiple changes in one commit — should be split. Option C uses ALL-CAPS and has no scope or detail. Option D uses a vague verb with an external reference — the commit message itself must be self-contained.