Skip links

Keeping track of your branches

September 2, 2015 at 8:45 AM - by Freek Lijten - 0 comments

Tags: ,

Anyone using a modern version control system has seen that branching really takes no effort. Git branches are easy and I'm sure this goes for other version control system. In my scrum team we tend to create feature branches for all changes that surpass "change the title of formelement X". This article describes (in short) my teams approach to managing all that branches.

Why do we create feature branches?

Time and time again we've done sprint reviews with nice results. And then the Product Owner says, now make sure feature 1,4 and 5 are live. For feature 2 I first want to write a manual and feature 3 got so much remarks during review that I want to put it up for work in the next sprints.

And we were like "uuuuhm..... yeah, all features are already committed to the same branch". Oops.

So we added feature branches. Basic exception: single commits. But it better not be anything more than the mentioned title-change or we'll be looking very stern at you.


In our strategy we have 4 types of branches:

Name Amount Commits allowed Merge allowed Purpose
mainline 1 No (well, only critical bugfixes) From accepted This is the code that implementations run on
accepted 1 No From accepted feature branches This is a branch where we fix merge conflicts and "store" accepted features
staging 1 No From feature branches This is the code that a testing-implementation runs on. Customers and we can play around here.
feature N Yes yolo Features, features everywhere

Basically we work on a feature in a feature branch. When we think it is ready we merge it to staging where team-members can test. If they are satisfied as well the customer can test and accept in the staging-implementation of their actual implementation. When they're happy we merge to accepted. Accepted gets merged into mainline on the final sprint day.

Keeping track

To keep track of all branches and their state we added a very simple tool. One paper from a flip-chart with a scheme of the branch types and a lot of post-its. Each feature branch get a separate post-it and is moved along the scheme according to its state. This is no rocket science but gives us a complete overview of all branches:

This basically is the full process. Sometimes we deviate for the sake of simplicity but we're happy with it. It is simple, has almost no overhead and is a great visualisation of our proces.

Share this post!


Leave a comment!

Italic and bold

*This is italic*, and _so is this_.
**This is bold**, and __so is this__.


This is a link to [Procurios](


A bulleted list can be made with:
- Minus-signs,
+ Add-signs,
* Or an asterisk.

A numbered list can be made with:
1. List item number 1.
2. List item number 2.


The text below creates a quote:
> This is the first line.
> This is the second line.


A text block with code can be created. Prefix a line with four spaces and a code-block will be made.