Glossary
What are Conventional Commits?
A convention for commit messages that changelogs and version numbers can be derived from. Structure, types, and what it is actually worth.
Conventional Commits is a convention for how a commit message is shaped so machines can read it: type(scope): description. The type says what the change means — and from that you can derive a changelog and the next version number.
The structure
feat(checkout): add Apple Pay · fix(auth): session survived a password change · docs(readme): add setup steps. Common types are feat, fix, docs, refactor, test and chore. A ! or a BREAKING CHANGE: paragraph marks a break.
Why bother
Because semantic versioning falls out of it: a fix bumps the patch, a feat the minor, a breaking change the major. The changelog then writes itself — from what actually happened rather than from what somebody remembers on Friday.
When it is not worth it
When nobody consumes the derivation. A convention that produces no changelog and no version is format-keeping for its own sake — a clear message in plain sentences does more.
In Zuuna
Zuuna enforces no format. It reads the card ID out of the commit message and links the work itself; Conventional Commits and a card ID in the same subject line coexist without trouble.
FAQ
Do I need Conventional Commits for Zuuna to link commits?
No. Zuuna looks for the card ID in the message or the branch name. The shape of the rest is up to you.
What is a breaking change?
A change after which existing usage stops working. It is marked with an exclamation mark after the type or a BREAKING CHANGE paragraph, and it bumps the major version.
Is it worth it for a small team?
Only if you use the derivation. Without a generated changelog or version scheme it is an extra rule with no return.