Conventional Commits

Every commit message follows the same structure. Machines parse it for changelogs and release decisions; humans scan it for a five-second history walk.

The format


<type>(<scope>): <subject>

# Example:
feat(auth): add login endpoint

Read as: “This is a new feature in the auth area that adds a login endpoint.”

Common types

Type	Means	Analogy
`feat`	A new feature was added	Adding a new room to a house
`fix`	A bug was fixed	Fixing a leaky faucet
`docs`	Only documentation changed	Updating the instruction manual
`refactor`	Code reorganized, behavior unchanged	Rearranging furniture, same room
`test`	Tests were added or updated	Adding a checklist to verify the faucet works
`build`	Build system or dependencies changed	Upgrading your tools
`ci`	CI/CD workflows changed	Adjusting the factory inspection process
`chore`	Maintenance work	Cleaning the garage

Why it matters

Scannable history. git log --oneline reads like a release note.
Automated changelogs. The version system parses types to generate release notes.
Semantic versioning. feat means minor bump, fix means patch, ! in the type means breaking.
Agent-friendly. The structured format is a contract the agent can verify before pushing.