Version control approaches in Scrum [closed]

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

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 2

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 3

That's a very interesting topic actually.

We always enforce branch per task creation, in fact, each task (not story, but actual tasks as decomposed after the scrum planning meeting) will have at least one associated branch.

You can see how it looks like at the following diagram:

This makes things like encouraging peer reviews very easy, since the team can checked what was modified on a task (branch), even when developers decided to make many intermediate commits (which is a very good practice!)

There's a number of links below that can be helpful:

1. Task per branch detailed
2. Go Agile in 4 steps!
3. And a screencast about it here.