Git Branching Model

Updated 1,145 Days AgoPublic

Actions

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.