Conventional Commits
Posted on:
sourceConventional commits seems to be the way forward as it's an easy set of rules to remember that results in a far more structured commit history.
Preferred Method
All commits require a type, scope, description, long form descriptive body and a ticket reference eg. #1234
They should be structured as follows:
feat(scope): I made a change
BREAKING CHANGE: This is a description of the change i've made
#1234
Quick reference
| scope | semver | description |
|---|---|---|
| feat | MINOR |
a new feature |
| fix | PATCH |
a bug fix () |
| docs | none | documentation only changes |
| style | none | changes that do not affect the meaning of the code (formatting etc.) |
| refactor | none | neither fixes a bug or adds a feature |
| perf | none | code change that improves performance |
| test | none | add or update existing tests only |
| build | none | affecting build system |
| chore | none | changes that do not modify source or test |
| revert | none | revert previous commit |
Adding BREAKING CHANGE to the body of the commit message will cause a MAJOR bump
Tools
Commitizen gives you a Q&A approach to committing, usually have it setup with:
yarn commit
Automagic SemVer as it works with Lerna to generate changelogs and determine version bumps