Git Branching Model
Updated 1,428 Days AgoPublic
Actions

Version 2 of 4: You are viewing an older version of this document, as it appeared on May 27 2020, 7:23 AM.

git-flow

Since MITK’s branching pattern and workflows were designed, Phabricator has been introduced, we improved our CI with Jenkins and many MITK-based projects are used in environments that require a reliable code base with plannable stable releases. As a research-oriented project in a fast moving environment we still have a high priority to be agile and open to contributions and experimental developments.

In May 2020, we decided to switch to the well-known and successful git-flow branching model introduced by Vincent Driessen in 2010: A successful Git branching model.

NOTE: If you are unfamiliar with git-flow, please read the arcticle linked 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 branched off from the develop branch and that are merged back into the develop branch. We check that each and every of these branches have an associated task by parsing the task number in the branch name. You must follow these naming conventions: