Considerations on approaches to reorganizing ouor development workflow to learn from Git-Flow and other models. One approach:

• Main development occurs on ‘master’, which is beta-level stable

  • Code that is merged to master is considered ready for release (fully developed and tested), so that the release manager can cut a release at any time of the features that have already been merged to master

• Unstable code is developed in feature branches

• Pull requests are issued against master

  • Merging pull requests should consider whether it is ready for release before merging the pull request. If not, a request can be made to retarget the pull request against a feature branch

• Releases are merged from master to ‘releases’ and tagged

  • Releases are named using semantic versioning (e.g., 1.1.1)

• Patch release branches are created from release tags as needed

• Patch releases are tagged on patch release branches

  • Merging or reapplying changes are both ok on patch release branches