. . "c824773eb0102d60bffd4033d9fc8348" . . . "2017-06-13T05:37:01Z" . "2017-06-13T05:37:01Z" . . "VOSGitUsage" . . "2017-06-13T05:37:01.851296"^^ . . . "2017-06-13T05:37:01.851296"^^ . "VOSGitUsage" . "VOSGitUsage" . . . . . "---+ Using Git With Virtuoso Open-source\n\n%TOC%\n\n---++ Introduction\n\nDue to the nature of its development cycle which includes several active\ndevelopment versions we apply a slightly more involved git usage paradigm as\ncompared to smaller OpenLink projects.\n\nThe main difference is that instead of a single =devel= branch we have more than\none which means a slightly more complicated management of releases and hot\nfixes.\n\n---++ Repository Setup\n\nWe use a moderated development model where there is one \"official\" repository\nthat is private. Only the administrator can push changes to this repository.\nDevelopers work in their own clones of the repository and send merge requests to\nthe administrator (details of this procedure are not clear yet. We might want to\nsetup or use a web frontend.)\n\n---++ Branches\n\nOur development model is based on the\n[[http://nvie.com/posts/a-successful-git-branching-model/][git workflow]]\noriginally presented by [[http://nvie.com/][Vincent Driessen]]. We have a master\nbranch which always reflects the current release, development branches for each\nversion of VOS, stable branches for each major release of VOS, feature branches\nand release branches. The only difference to the mentioned git flow system is\nthat we have more than one stable branch - where git flow (and other smaller\nOpenLink projects) uses branch =master= for tracking the current stable state,\nwe use branches prefixed =stable=.\n\nLet us look at the branches in detail.\n\n---+++ The main branches\n\nWe have a set of main branches with an infinite lifetime, its number depends on\nthe number of currently developed versions of VOS. Here we assume that we work\non VOS6 and VOS7 in parallel, VOS6 being the production version. This results in\ntwo main development branches:\n\n * develop/5\n * develop/6\n * develop/7\n\nThe branch develop/6 always reflects the latest state in active\ndevelopment of the VOS6 series. New features are integrated here.\n\nIn addition we have one branch for each major release of VOS:\n\n * stable/5\n * stable/6\n * stable/7\n\nThese are branched off their respective =develop= branches whenever a new major\nrelease is about to be created.\n\nThe =master= branch always matches the latest stable release; release tags are\nonly created on the =master= branch.\n\n---+++ Feature branches\n\nNew features are developed in feature-branches (sometimes called topic\nbranches). Feature branches typically have the prefix feature/ and should\nalways be branched off a development branch:\n\n\n$ git checkout -b feature/myFeature develop/6\n\n\nOnce the feature is done it should be merged back into the originating branch:\n\n\n$ git checkout develop/6\n$ git merge --no-ff feature/myFeature\n$ git branch -d feature/myFeature\n\n\nThe --no-ff flag causes the merge to always create a new commit object,\neven if the merge could be performed with a fast-forward. This avoids losing\ninformation about the historical existence of a feature branch and groups\ntogether all commits that together added the feature.\n\nFor the time being we also allow features to be branched offs table major\nrelease branches for convenience. This, however, results in a slightly more\ncomplicated procedure. First we have to branch off the stable branch:\n\n\n$ git checkout -b feature/myFeature stable/6\n\n\nOnce the feature is done it is merged back into the stable branch:\n\n$ git checkout stable/6\n$ git merge --no-ff feature/myFeature\n\n\nBut the feature also has to be merged into the devel branch before being deleted:\n\n$ git checkout develop/6\n$ git merge --no-ff feature/myFeature\n$ git branch -d feature/myFeature\n\n\n\n---++ Tagging a release\n\nA release is always tagged from a stable branch. Since =master= should always\nreflect the current recommended stable version of VOS it does not need to be\nupdated on every release. Imagine for example a bugfix release of VOS6 when VOS7\nhas already been released.\n\nAs soon as a =develop= branch has reached a stable state fit for a release a\nrelease branch is created in which the rest of the release preparation like\nversion bump, ChangeLog updates, and so on are done:\n\n$ git branch -b release/6.2.2 develop/6\n\n\nOnce the branch is done it is merged back into the originating branch and the\ncorresponding =stable= branch:\n\n$ git checkout branch develop/6\n$ git merge --no-ff release/6.2.2\n$ git checkout stable/6\n$ git merge --no-ff release/6.2.2\n\n\nThen the release is tagged from the =stable= branch:\n\n$ git checkout stable/6\n$ git tag -s v/6.2.2\n\n\nIn case this new release is the latest recommended version the release branch also has to be merged into =master=.\n\n$ git checkout master\n$ git merge --no-ff release/6.2.2\n\n\nDue to the nature of VOS development two develop branches may diverge a lot\nmaking it virtually impossible to merge one into the other. Thus, if the release\nintroduces a new major VOS version, master needs to be updated in a special way,\nessentially throwing away all the changes from the old major version. This can\nbe achieved by specifying a special merge method:\n\n\n$ git checkout master\n$ git merge -Xtheirs --no-ff release/6.2.2\n\n\nAnd finally the release branch can be removed:\n\n\n$ git branch -d release/6.2.2\n\n\n---+++ Hotfix Releases\n\nSometimes there is the need to release a hotfix. A hotfix is a small bugfix\nrelease which does not necessarily be based on the latest stable release. If\nversion 6.2.0 was the latest stable release some people might still use 6.1.3\nbecause they fear the maintenance hassle with updating to another major version.\nThus, if a bug is found in 6.1.3 a hotfix release 6.1.4 needs to be released.\nThis is done by branching off a tag:\n\n\n$ git checkout -b hotfix/myFix v6.1.3\n\n\nOnce the fix is done it might require merging back into the stable and/or the\ndevelop branch, depending on whether the fix still applies in the newer\nversions:\n\n\n$ git checkout stable/6\n$ git merge --no-ff hotfix/myFix\n$ git checkout develop/6\n$ git merge --no-ff hotfix/myFix\n\n\nTagging a hotfix release is a little different from normal release tagging as\ndescribed above. Since master is not touched we tag the release directly in the\nhotfix branch and then delete it:\n\n\n$ git checkout hotfix/myFix\n$ git tag -s v/6.1.3\n$ git branch -d hotfix/myFix\n\n\n---++References\n\nSee also:\n * [[GitQuickstartTips][Git Quickstart and Tips]]\n * [[http://progit.org/book/][ProGit - Online-Book on Git Usage]]\n * [[http://help.github.com/][GitHub Help]]\n\n" . . . . . . . . .