Create a new branch whenever you start working on something. Don't commit to main or development, as these branches are used for the production and staging environments and need to be stable.
Branch names are up to you, but we recommend including the issue number and a brief title. You can also prefix branch names with feature/, fix/, or other categories.
The main Branch
The main branch reflects our currently deployed production state. Most PRs should never be merged directly into main, but rather development.
We will create a new PR to merge the delta between staging and production regularly.
The development Branch
Once you finish a task and create a PR for it, it should merge into development, the equivalent of a staging environment. Don't merge work that isn't done yet. Instead, if more PRs are about to follow, combine them into a feature branch.
Working on more significant issues means that a couple of PRs need to be merged first before releasing the feature to development. That's what you can use feature branches for.
Please prefix feature branches with feature/ to make it transparent, e.g.:
We use conventional commits across all repositories. This means that our commit messages have a certain structure:
<type>[optional scope]: <description>
The commit type can include the following:
feat: a new feature is introduced with the changes
fix: a bug fix has occurred
chore: changes that do not relate to a fix or feature and don't modify src or test files (for example, updating dependencies)
refactor: refactored code that neither fixes a bug nor adds a feature
docs: updates to documentation such as a README or other markdown files
style: changes that do not affect the meaning of the code, likely related to code formatting such as white space, missing semi-colons, and so on
test: including new or correcting previous tests
perf: performance improvements
ci: continuous integration-related
build: changes that affect the build system or external dependencies
revert: reverts a previous commit
The commit-type subject line should be lowercase with a character limit to encourage succinct descriptions. The optional commit body should be used to provide further detail that cannot fit within the character limitations of the subject line description.
Below is an example of a conventional commit:
fix: remove duplicate entry in router
This fixes the problem of the navigation not working
properly and instead putting the new page at the bottom.