back home

🌳 Conventional Commits

#conventional#commits#commitizen#quick#reference#committing#git

Conventional 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