Version 1 vs 4
Version 1 vs 4
Content Changes
Content Changes
= 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.
We decided in May 2020 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 short and excellent 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 =
== Code guarantees ==
== Code review ==
== Releases ==
= Examples =
= git-flow =
In May 2020, we decided to switch to the well-established //git-flow// branching model introduced by Vincent Driessen:
{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 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:
```lang=bash
$ 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 [[mitk/dev/master-merge]].
== Code guarantees ==
We give different code guarantees for different branch types, expressed as quality levels. See [[mitk/dev/guarantees]] for more details.
= 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.In May 2020, 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.we decided to switch to the well-established //git-flow// branching model introduced by Vincent Driessen:
We decided in May 2020 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 short and excellent arcticle linkarticle 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 =
== Code guarantees ==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//
== Code review ==The same naming convention is applied to release and hotfix branches, prefixed by //release/// or //hotfix/// respectively.
== Releases ==== Branch lifetime ==
= Examples =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:
```lang=bash
$ 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 [[mitk/dev/master-merge]].
== Code guarantees ==
We give different code guarantees for different branch types, expressed as quality levels. See [[mitk/dev/guarantees]] for more details.