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,
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.
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.
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.
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
master branches they are deleted.
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.
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.