Change Details

= 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 = 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 arcticle linkmentioned 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. You must fFollow these naming conventions: - feature/T12345-foobar//short-description// - bugfix/T12345-foobar//short-description// For now, we still allow the oldThe same naming convention (T12345-foobar)is applied to ease the transition towards //git-flow//release and hotfix branches, but it will stop working any time soonprefixed by //release/// or //hotfix/// respectively. == Code guarantees == == Code review ==== Branch lifetime == == Releases ==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: = Examples =```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.