Here are guidelines we would like you to follow are:
This repository has two core branches: main (production) and develop.
Normal workflow: develop
-> main
(tag latest commit)
New features should have its own branches with name format: [type]/[branch-name]
where type follows commit type.
Release tag should be made on the latest in master after merging develop
to main
.
Naming convention with semantic versioning: release-YYYYMMDD-vX.Y.Z
Branch off of main and upon completion of fix, merge into main
(tag hotfix) and develop
as a merge commit.
Before you submit your Pull Request (PR) for a non-hotfix task, consider the following guidelines:
- Branch off of
develop
asfeature/my-new-feature
- Add your update, including appropriate test cases.
- Run the full test suite and ensure all tests pass.
- Commit your changes using a descriptive commit message that follows our commit message conventions.
- Open PR to
develop
and make any requested changes (if any)
If you're merging a PR that addresses one single feature or bugfix:
- Before merging your PR, please change the name as the name must follow commit message conventions
- Squash and Merge your changes into
develop
, this will make it easier to revert specific features, bugfixes, or issues if the need arises.
If you're merging a PR that addresses multiple features and/or bugfixes:
- Use your best judgement whether to
Squash and Merge
orCreate a merge commit
Squash and merge
will merge your changes intodevelop
as a single commitCreate a merge commit
will merge your changes intodevelop
including all the commits made in your main branch.
When submitting your PR for a hotfix tasks, please follow the following:
- Branch off the
main
branch - Open PR to
main
- After hotfix is merged into main, merge the hotfix changes to develop as a
merge commit
type.
We have guidelines on how git commit messages can be formatted. This leads to more readable messages that are easy to follow when looking through the project history.
TBC
TBC
Must be one of the following:
TBC
TBC
TBC
TBC
TBC