Branching strategy
The branching strategy this project uses is simple. We use three types of branches feature branches, release branches and the master branch.
While pull requests to main do trigger our CI pipeline the branch is not meant to be completely stable. Try to merge often to the master branch in order to avoid merge conflicts and to keep master from falling too far behind.
Release branches should have completely stable, ready for release code.
They should be name in the form of release/version.major.
Merges to release branches trigger our CD pipeline and push an image to docker hub.
If you make changes to a release branch in preparation for a new release merge the feature branch back into main so we don't lose any changes.
Feature branches are our most unstable branches. These are the branches where most of our commits are made -- they're basically the wild west.
Try to merge feature branches -- whenever in a presentable state -- into master often.
They should be named in the form of feat/issue#-description
