Repository navigation
Branching Model
The master branch should never be developed on directly. It should only receive merges from the release (or patch) branch once that release has been deployed to production.
The master branch is never deleted.
Features should always be developed on their own feature branch, which should be named according to the JiraID for the feature (eg METL-123). Multiple related features, and subtasks of the main feature, may share the same branch.
Feature branches are always created from master.
Feature branches are deleted once they have been deployed to production.
Feature branches are merged into the release branch to create a candidate for the next scheduled release.
The release branch is never deleted during normal procedure, but may be reset, rebranched or recreated if a release candidate is discarded and recreated with a different set of features.
The patch branch is for hotfixes required when the release branch is already allocated to the next scheduled release. It should have master merged into it, then have hotfixes done on it directly.
Feature branches are merged into the future branch to create a candidate for a release that is after the next scheduled release. This will target a different test environment (currently https://future.stackableregiments.com).
The future branch is never deleted, but may become dormant if there is no need for it.