Which branch should I be working on?

Here at Clock we have recently switched from svn to git; it is awesome. If you don't already know that you should try it for a month. Git is both powerful and flexible and this allows you to adopt sophisticated branching models which can improve the quality of your development process and alleviate developer headaches. Even before we switched to git we had prescribed to a branching model based on Vincent Driessen's excellent post. However with the nightmare that is svn merging, we kept our branching reserved for major features. Since switching to git we now have the luxury of creating a branch for the smallest of changes, safe in the knowledge that we can merge it back ready for deployment without losing any hair.

This model works really well but can be quite a daunting process to follow, especially if your team is a mixture of developers, designers, and content editors who are new to git. Thankfully everybody on the Clock team has bought into using git and can see the benefits. But it is a steep learning curve coming from svn where all day-to-day SCM tasks could be performed easily via a gui menu in a developer's IDE. Some training and group learning is definitely required. For Clock I ran a number of workshops to introduce git to the production staff and explain how the svn use cases translated to git. On top of that many team members have spent their own time learning how to tame the vast sheathe of power and flexibility that git affords you. There are great resources out there such as the excellent 'Git Immersion' by EDGECASE which are accessible to nearly any level of developer.

I have found that even if you know the the basics of git and understanding the branching model theory, it still isn't always clear what branch developers should be working on. This is compounded by the fact that we develop and maintain many sites; some big with many developers and some small with maybe only one developer responsible for updates. Vincent's branching model is good but it can be an overhead on small projects; so we are happy for the developers on a project on to choose how they manage their repos. As is true with all freedom of choice, the more free reign you allow, the greater the uncertainty that the correct path is being followed. Nobody likes strict rules, but nobody likes uncertainty either (except maybe Schrödinger's cat) so to help with this process I put together a flow diagram which aims to help you choose the correct branch to work on for a given task. It is nothing ground breaking, but I thought that others might benefit from a little insight into how we go about making that decision. Click the image for the PDF Version.

If you have any feedback or experience with alternative branching models that work well in agency environments please leave a comment.