Please follow the established branching strategy. In the event of divergence from the README, the external document will take precedence.
All commit messages must be written in the Conventional Commit Format.
You must ensure that you are using the correct commit type.
These should be used appropriately - for instance, if you are refactoring the
repo structure without changing any of the application, this would be appropriate to
use chore. If you are fixing a bug then fix should be used. A new feature should
use the type feat.
It's very important that PRs have linear commits. There can be multiple commits per PR (if appropriate), but they should be linear. An example of a non-linear commit is:
7fa9388 (feature/my-wonderful-feature): feat(some-brilliant-feat): this is a brilliant feature I've worked hard on
bf2a09e erm, not sure why CI has broken so another go
067c88e gah, I'm stupid. I can see why CI brokeThis is not linear because you're fixing something inside the PR. This should be rebased so it's linear:
6fd721a (feature/my-wonderful-feature): feat(some-brilliant-feat): this is a brilliant feature I've worked hard onLinear commits are much easier to find problems when tracing through Git history.
To automatically generate the format correctly, please use Commitizen to make all commits to this repo. This repo is Commitizen-friendly.
There is linting on commit messages in the repo, both in GitHub Actions and as a commit hook.
Either:
npm install -g commitizen
And then:
git add .
git cz
Or:
git add .
npm run commit