A git branching model

This is a git branching model I've used in a few organizations.

It's not a new approach, but since I can't find it described in detail elsewhere on the web I'll share it here.

It's halfway between GitHub flow and Gitflow in terms of the number of operations involved.

• A long-lived main branch exists as the source of truth
  • The main branch has protections that prevent deletion and direct pushes
• Short-lived feature, fix, refactor and test branches branch from main and are merged back into main after a pull request review
  • Examples of branch names: feat-table-widget, fix-table-event-handling, refactor-table-cell-views, test-table-actions
  • These branches are deleted after merge into main
• On a predetermined date, a new long-lived release branch is created
  • Releases may only be planned for major and minor version bumps, not patch bumps (see semver for definitions)
  • The process of creating a release branch is referred to as a branch cut
  • Examples of branch names: release-0.1, release-0.2, release-1.0
  • Release branches have protections that prevent deletion and direct pushes
• After a new release branch is created, the branch undergoes a predetermined stabilization period
• If a significant defect fix need be applied to a release during the stabilization period, a backport may be performed
  • Only significant defects as determined by the release lead should be backported
  • Feature, test, refactor and minor defect fixes should instead land in the release after next
  • If changes need be applied to the release branch, they must first be reviewed and merged into main
  • Then, create a short-lived branch from the release branch, cherry-pick the fix and create a PR to be merged into the release branch
  • Merge the PR into the release branch
• At the end of a predetermined stabilization period, perform the release for the project using the release branch
• If urgent bug fixes need be applied to a release after deployment, a hotfix may be applied using the same process as described above for backports
  • Only urgent fixes as determined by the release lead should be backported
  • In addition to the backport process, a patch bump commit is applied after a fix is merged into the release branch (e.g. version 0.1.0 → 0.1.1)
  • After the patch bump, a new deployment is performed

Thanks for reading! Go home for more notes.