We use conventional commits in order to automatically define versions and create a changelog. THis will help us keep a better overview of what has changed over time or was added in the last version.
All commits are linted, so you will not be able to commit until your message follows our rules. Please read conventional commits to get a better understanding on why this is helpful and how this works. You can also look at Semantic Versioning if you are interested in more detail about versioning.
A good commit message is important for us for several reasons:
- Automate Semantic Versions
- Automate changelog
- Give consumers and contributors a chance to easily understand what has been done
In general the following rule applies:
Keep messages short and concise.
Chore commits should be used in the following cases:
- Update dependencies
- Update scripts in package.json
- Update files outside the Source folder
- Update configuration files
Update dependencies:
chore: update dependencies
## OR
chore(dependencies): update dependencies
Update config files:
chore: adjust xo configuration
## OR
chore(xo): update configuration
## OR
chore(hooks): add pre-commit hook
Docs commits should be used in the following cases:
- Update documentation files
- Update comments or doc-blocks in source files
Update documentation:
docs: typo in readme
## OR
docs(button): api changes
Test commits should be used in the following cases:
- Update test files
Update test:
test: add test for signin
## OR
test(signin): added new test case
Fix commits should only contain bug-fixes.
Fix bug:
fix: checkbox state was inverted
## OR
fix(checkbox): checked state was inverted
## OR
fix(checkbox): state was inverted
checking a checkbox was wrong when the outside state changed
fixes: #123
Feature commits should be used for every feature-story. Each story is on feature.
Add feature:
feat(signup): add signup screen
#OR
feat(signup): tighten password rules
BREAKING CHANGE Users might need to update their password