Branching and development strategies

The kiosk-console repo was set up to use a gitflow branching style where we use dev (previously stable) to merge feature PRs and stage them, then merge to master for a new release. Here are some details on each of the "special" branches:

• master - this branch is the main branch for the project and is the branch that we cut releases from. Only PRs from the dev branch should get merged into master. Integration tests run on PRs to master.
• dev (previously stable) - this branch is where all the changes are merged to - changes will accrue in the dev branch and get all merged into master at once. Feature branches (for upgrading a helm chart or version) should get merged into dev. Typically after a merge to master, I delete the dev branch and re-push it for a clean commit history. This requires turning on/off/on the branch rules for dev (I usually just change the pattern to dev-temp and change it back when the new branch exists)
• production - this should represent the current state of the production cluster since every configuration can be saved in code/environment variables. Deploying a new prod cluster should use this branch to build & run the image.