Git Branching Model
git-flow
In May 2020, we decided to switch to the well-established git-flow branching model introduced by Vincent Driessen:
A successful Git branching model
Additional policies
Branch naming conventions
Bugs and features are fixed and implemented in branches that branch off from the develop branch and that are merged back into the develop branch. We check that these branches have an associated task by parsing the branch name for a task number. Follow these naming conventions:
- feature/T12345-short-description
- bugfix/T12345-short-description
The same naming convention is applied to release and hotfix branches, prefixed by release/ or hotfix/ respectively.
Branch lifetime
After a branch was merged without fast-forwarding (git merge --no-ff) into develop or master, make sure to delete it at least from the remote (origin). Usually, you also want to delete it locally:
$ git push origin --delete bugfix/T12345-example $ git branch --delete bugfix/T12345-example
Master merges
Release branches are merged into the master branch. Each one of these merge commits is tagged as either a snapshot or an official release. Since we want to make these tags available in develop as well, we deviate from the original git-flow article. Instead of merging release branches directly into master and develop, the master branch is merged back into develop, after the release branch was merged into master.
For details, see Merging into master Branch.
Code guarantees
We give different code guarantees for different branch types, expressed as quality levels. See Code Guarantees for more details.
- Last Author
- kislinsk
- Last Edited
- Mar 1 2021, 9:41 AM