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
- Make use of automatic Semantic Versions
- Generate a change changelog
- Give 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 NPM packages
- Update NPM scripts
- Update files outside the Source folder
- Update configuration files
Updating npm packages:
chore: update packages
## OR
chore(npm): update packages
Updating config files:
chore: adjust xo.config
## 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 commit 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