= 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: {icon arrow-right} [[https://nvie.com/posts/a-successful-git-branching-model/|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:
- feature/T12345-foobar
- bugfix/T12345-foobar
== Code guarantees ==
== Code review ==
== Releases ==
= Examples =