Our git workflow

When we started Eduhub we used to do version control with SVN, but soon changed to git because of it’s more flexible nature and speed. At first we didn’t really feel git so we were struggling to find a good workflow. After discussing different workflows with some other developers we settled on the following workflow, adapted from this git workflow by nvie.

This post has been updated on May 20th, 2011, see what is new down below.

Two main branches, no release branch

This workflow uses a master branch which contains the last stable release, a release branch per release which contains all the features from one release and separate feature branches, one for each feature being developed. We slightly modified this workflow and removed the release branch from it, because we don’t use compound releases, we just release features as soon as they are done.

In stead we use two eternal branches, dev and master which contain current development code and live code respectively. Features and bugfixes are developed in their own dedicated branches and merged into dev upon completion for staging and into master when tested thoroughly and marked for release.

The master branch

This branch contains the latest stable code that also runs on our production servers. It is an eternal branch in the sense that it has an infinite lifespan and will not be merged into another branch. All new features and bug fixes are branched off this branch.

The dev branch

This branch contains the latest code unstable code. Just like the master branch this branch is a branch with an infinite lifespan. New features are first merged into this branch so they can be user tested before deploying them.

Local branches

These branches contain new features or bug fixes and are branched off the master branch. To avoid huge conflicts at merge time, local feature branches are rebased on master branch every now and then. Once they are merged into the dev and master branches they are deleted.

Benefits

The biggest benefit of this workflow is the ability to keep new features separated from each other during development and incorporate these features into the live code at anytime we want. A feature that has a longer development cycle than another feature will not hold up the deployment of the latter as they are being developed independent of each other.

Update

Recently we’ve chosen to abandon the dev branch and use one eternal branch, the master branch, instead. The reason is pretty straightforward: it was too much hassle to maintain two branches and the dev branch didn’t really have any value anymore, it just made things more complicated.

If we want to test a new feature for a while, we just deploy it’s feature branch on a test machine so it’s available for all. Production-ready feature branches get merged into the master branch which is automatically deployed to our dev server. We then deploy the master branch to our production machines by hand, using DeployHQ.