Page MenuHomePhabricator

Git Branching Model
Updated 1,235 Days AgoPublic


In May 2020, we decided to switch to the well-established git-flow branching model introduced by Vincent Driessen:

A successful Git branching model

NOTE: If you are unfamiliar with git-flow, please read the article mentioned above. For the rest of this page, we assume that you understood the basics of git-flow and focus on additional policies we introduced on top of this 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
Last Edited
Mar 1 2021, 9:41 AM

Event Timeline

kislinsk published a new version of this document.