This page describes the basics of your workflow, which is basically the same as Vincent Driessen described in this blog.

This page is currently under construction.


branch master
We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state. Each commit to master is considered a new release and will be tagged.
branch develop
We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”.
This is where any automatic nightly builds are built from.
release branches
These branches are for preparing the next release. This is for example: updating the version numbers, completing the change-log, recompiling the loader, rebuilding the manuals. See Development/HowtoRelease for details about the release process and what steps have to be performed.
hotfix branches
These branches are also meant to prepare for a new production release, albeit unplanned. This is what is commonly known as a "hotfix".
feature branches
Feature branches (or sometimes called topic branches) are used to develop new features for the upcoming or a distant future release.

We do not need long living branches as we do not support bugfixes for several major releases in parallel.


  • Occasional contributors use a fork at github (or somewhere else) and send pull requests.

One of the core developers should test it and then merge it or ask for other improvements of that patch set.

  • Regular contributors (aka "core developers") use the central repository.
    • Core developers work mostly in feature branches. The purpose thereof is to avoid silly errors in the develop branch.
    • feature branches should whenever the change is more than as single commit. This helps
    • feature branches are created for a
      • bug, named like 'feature/bug-1234-this_is_about_the_bug'
      • issue, named like 'feature/bug-1234_this_is_about_the_issue'
      • feature, named like 'feature/this_is_feature_name'
    • When testing is required, the feature branch can be pushed to the central repository or to another personal repository. So other developers can test the code.
    • If a core developer wants some comments for his/her code, then he/she creates a pull request and another core developers should review it and merge.
    • When the code from feature branches are ready, merge it into develop using --no-ff and close delete) the feature branch.


  • New hooks go into develop.
  • Bug fixes for existing hooks go into a hotfix.
  • If existing hooks do not support newer versions of the "hooked" modules, this is a bug, too.
  • Enhancements for existing hooks (e.g suppurt for Qt4 -> Qt5) go into develop.


Merge the feature-branch back like

$ git checkout develop
$ git pull              #  <<<--------
$ git merge --no-ff myfeature
$ git branch -d myfeature
$ git push origin develop


$ git checkout develop
$ git pull                     #  <<<--------
$ git rebase develop myfeatre  #  <<<--------
$ git merge --no-ff myfeature
$ git branch -d myfeature
$ git push origin develop

Or (untested)

$ git checkout develop
$ git pull                #  <<<-------- update
$ git checkout myfeature
$ git merge develop       #  <<<-------- merge into branch
$ git checkout develop
$ git merge --no-ff myfeature
$ git branch -d myfeature
$ git push origin develop

Tag Names

Releases are tagged on branch master with the prefix "v" and following this structure:

v1.5-a1  # when using alpha versions
v1.5-b1  # when using beta versions

tdb: How to tag. Put this into Development/HowtoRelease.

Transition the to new workflow

We currently have a long living branch-1.5 where we are preparing the upcoming 1.5. release.

Adopting the 1.5.2 release with nvie model:

  • finish fixes in hotfix-1.5.2 branch
  • test it
  • merge 1.5.2 into 'master', tag it, release it
  • merge 1.5.2 changes into 'develop' if necessary
  • delete (close) 1.5.2 branch
  • continue with further development on 'develop'
  • when sticking with nvie, master should reflect code of 1.5.1 and 1.5 branch should be considered as hotfix branch.
  • 1.5 branch is in git a short-living 'hotfix-1.5.2' branch

Our current svn branching workflow:

  1. Stabilize code in trunk for release.
    nvie: create a release branch from 'develop'
  2. Do release (1.5) nvie:
    1. merge release branch to 'master'
    2. merge release branch to 'develop'
    3. delete release branch (not needed anymore)
  3. Create a tag.
    nvie: create a tag on 'master' HEAD.
  4. Create a 1.5 branch for further possible bugfix releases.
    nvie: do nothing
  5. Do bugfixes only in Long-living branch 1.5 and backport it to trunk
    1. create hotfix branch '1.5.x' from 'master' HEAD.
    2. merge hotfix branch to 'master' HEAD
    3. tag '1.5.x' on 'master' and do a bug fix release
    4. merge hotfix branch to 'develop'
    5. delete hotfix branch
    6. for a new 1.5.x release start again with item a)).
Last modified 3 years ago Last modified on Feb 10, 2012 2:50:36 PM