20

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.

Ólafur Waage
  • 68,817
  • 22
  • 142
  • 198
Sam
  • 6,437
  • 6
  • 33
  • 41
  • I found a very valuable and exhaustive resource for agile or Scrum version control to be an [article on InfoQ: ](http://www.infoq.com/articles/agile-version-control) This article really answers a lot of questions and gives good ideas on agile version control with multiple teams. – KingOfCoders Mar 10 '09 at 15:53

7 Answers7

8

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.

Andy Hume
  • 40,474
  • 10
  • 47
  • 58
  • How is branching for individual features keeping things lightweight? You always have to pay integration costs, whether when checking into the trunk, or when merging branches. I prefer not to have to merge branches unless it's really necessary. – Chris Ballance Mar 10 '09 at 00:02
  • 1
    I mean keep the protocol leight-weight. 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. – Andy Hume Mar 10 '09 at 00:06
  • Your last paragraph is an important part of "not being afraid to branch" working effectively. Each developer has to assume the responsibilities you outlined. – Chris Ballance Nov 29 '13 at 23:39
5

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.

Chris Ballance
  • 33,810
  • 26
  • 104
  • 151
  • 3
    I see your point, but sometimes a problem that arises with single codebases is that people is afraid of commiting until having the feature completed to avoid breaking everyone's code. Thus, losing the advantages of versioning in first place. – Sam Mar 10 '09 at 00:09
  • That's absolutely not a problem so long as this is the exception rather than the rule – Chris Ballance Mar 10 '09 at 00:14
4

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.

Community
  • 1
  • 1
Henrik Gustafsson
  • 51,180
  • 9
  • 47
  • 60
4

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: alt text

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.
Community
  • 1
  • 1
pablo
  • 6,392
  • 4
  • 42
  • 62
1

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

John Saunders
  • 160,644
  • 26
  • 247
  • 397
1

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.

David Pokluda
  • 10,693
  • 5
  • 28
  • 26
-1

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.

DancesWithBamboo
  • 4,176
  • 1
  • 19
  • 20
  • 1
    I came from a company where one branch per ticket (story, in this case). It works well because you isolate changes for each piece of work, and can check in frequently without fear of breaking the main line. Strict merge policy prevented incomplete or broken code making it to mainline too. – Adam Hawes Mar 10 '09 at 01:55
  • If you work with git or other DVCS system the overhead of branch management is extremely low. If you work with SVN or other similarly styled SCMs that don't handle merging well then no, BPF is not really cost effective. – Chris Nicola Jul 19 '10 at 20:49
  • I have never been on a project where the longest stories took only 2 days. I question whether your user stories were really delivering business value. – Robin Green Aug 18 '15 at 14:16