Version control approaches in Scrum

Question

Recently with my coworkers we were discussing how to organize the version control in a Scrum project. More specifically, the criteria for branches creation (per developer, per task, per Story, per Sprint?) and the methods of integration.

My opinion was that a useful way to organize it is to create a branch for each User Story, so you can integrate each Story in the releasable trunk once it is completed and it also allows that you always have a "deliverable version" of the application at any moment.

So if a story cannot be completed, it can be just left out and does not compromise the sprint release. (That considering a centralized tool, may be if using a distributed one the considerations would be different)

I'd like to know your own approaches, which kind of tools you prefer and the pros and cons that you have seen with the experience and the lessons learned.

Answer 1

A branch per user story sounds quite excessive to me. We keep a single code base (trunk) and work out of this. The only time we would normally branch is to fix a current production problem which could not wait until a regular release.

Answer 2

Keep branching protocol light-weight. In Scrum, if someone wants to branch the code to work on a specific feature, let them. Nobody should be afraid to branch. This is one of the benefits of DVCS - people branch when they want and aren't biased by team rules or standards.

For my money, it's a case-by-case basis, and if you start seeing patterns in your development processes then formalize them so everyone is on the same page.

Just make sure that every developer understands that it is their responsibility to integrate and merge their changes. That should set the bar to around about the right place to ensure people make the right call as to when to branch the code.

Answer 3

I would use one branch per release, and use Continuous Integration to keep one user story from damaging the others.

Answer 4

I don't see how a branch per feature can make you more agile or lean. The cost of branch management is just too high. I would argue that if you feel you need a branch per feature then your stories are too big. A story should be completed by the next scrum and if not, certainly by the next one. So if a branch only exists for 1-2 days I don't see how it can be useful or its cost repaid. It is routine for many people to work on a story so I sometimes use a dev branch for developers to work in so that they can merge code Many times per day while working on the same story without the code being deployed to test (main branch). Ideally you would have so few stories in progress and complete them so fast that you would only need the Main branch and no others.

Answer 5

The only change you should do to your source versioning system is to integrate it with the continuous integration system (like TeamCity or CruiseControl.NET).

Yeah I know that I am not really answering your question but I really mean it. In agile software project you want to be able to release the product to customers (or be able to) as often as possible. That's why you need to know that whatever is in your source system is working or if it is not working why it is not working.

Answer 6

I found a very valuable and exhaustive resource for agile or Scrum version control to be an article on InfoQ:

This article really answers a lot of questions and gives good ideas on agile version control with multiple teams.

Answer 7

Whenever we have a story or a set of stories that threatens to leave the master branch in disarray for several days or involves 'many' developers we create a branch for that (not very common, we try to task things to avoid this, but it happens) as a sort of risk-mitigation thing. We want to be sure that the master branch is always ready for release at the end of each sprint, even if it potentially means that we might not have increased the value of the master branch after the sprint.

The story/feature/task branch is synchronized against the master branch very often, and the goal is to always have the branch merged back well before the end of the sprint.

Of course, we all use 'git', so in effect we always have a local branch that we work on, and we've become pretty good at synchronizing with master often enough to avoid big-bang integrations and seldom enough to not leave useless/unused code in the master branch.

Other than that, we do 'branch-by-purpose' (PDF). I also wrote a bit more about how we do git here.