Keeping track of your branches
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.
Branchtypes
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.
After about 10 years of professional development at both