Table of Contents
git can be used in a variety of ways.
In fact it allows so many ways of managing ones code that it is easy to mess everything up.
Thus, it is important to stick to fixed policies and rules when using a git repository collaboratively.
This document states the setup and the policies used with the VOS git-repository.
We use a moderated development model where there is one "official" repository that is maintained by OpenLink Software. Only OpenLink can push changes to this repository. Developers work in their own clones of the repository and send merge requests or patches to the administrator. (Details of this procedure are not clear yet. We might want to setup or use a web frontend.)
Our development model is based on the git workflow originally presented by nvie. We have a master branch which always reflects the current release, a development branch, stable branches for each major release, feature branches, and release branches.
All the procedures described below can also be performed via the git-flow extension.
Let us look at the branches in detail.
We have two main branches with an infinite lifetime.
- The branch
developalways reflects the latest state in active development. New features are always integrated here.
masterbranch always matches the latest stable release, release tags are only created on the
New features are developed in feature-branches (sometimes called topic branches). Feature branches typically have the prefix =feature/= and should always be branched off the development branch:
$ git checkout -b feature/myFeature develop
Once the feature is done it should be merged back into the originating branch:
$ git checkout develop $ git merge --no-ff feature/myFeature $ git branch -d feature/myFeature
The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature.
A minor release is created from a stable version branch like
A release branch is created in which the rest of the release preparation like version bump, ChangeLog updates, and so on are done:
$ git branch -b release/1.2.2 master
Once the branch is done it is merged back into
$ git checkout branch master $ git merge --no-ff release/1.2.2
It also has to be merged into the development branch (this might lead to conflicts which need to be resolved):
$ git checkout develop $ git merge --no-ff release/1.2.2
Then the release is tagged from
$ git checkout master $ git tag -s v/1.2.2
and finally the release branch can be removed:
$ git branch -d release/1.2.2
Bug fixes that will go into a minor release (and as such are not considered a feature to be branched off the
develop branch) need to be branched off the
$ git checkout -b hotfix/myFix master
Once the fix is done it is merged back into the
$ git checkout master $ git merge --no-ff hotfix/myFix
In case the fix also applies to the latest development version the branch has also to be merged into the
develop branch before being deleted:
$ git checkout develop $ git merge --no-ff hotfix/myFix $ git branch -d hotfix/myFix