Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We are moving our project's team from using a single Main/Trunk branch, to multiple Development/Work branches that should be regularly merged into Main. We're basing our new process on this article and the TFS Branching Guide (we are using TFS and Visual Studio 2010).

There are currently between 1 and 5 people working on the project at any one time. Main must be stable at all times because we want the option to release whenever we need. We don't have fixed sprints - at least not yet - and at the moment release every 1-2 weeks.

Right at this point in time each person is fixing bugs across the application. In a couple of weeks we will be starting development on a new large component for the app.

One sticking point we are finding is when development branches should be created. We will be implementing multiple user stories in parallel depending on the skill set of the developer. We've thought about creating a branch for each developer but that doesn't make sense because there will always be some need for collaboration on a piece of work. We can't get by with a single development branch because we will want to merge to Main while other work is completed.

Does anyone have some guidance on this?

share|improve this question
God bless your soul for using TFS and creating branches. At a previous phase in my company they decided to use TFS, and eventually all the developers became so scared of the merging process that branching turned into Programmer Fear Factor. – Jordan Sep 6 '11 at 4:16

I'm not fond of arbitrary branches i.e. Fred's bugfixes or Harry's bugfixes. I'm much more comfortable with one (independent) feature one branch which allows multiple developers to operate on one feature; but for the feature to be merged only when it's complete.

So, right now you only need the "bugfix" branch but once you start development you should crate a branch for every significant feature. That way when they are done they can be merged in & released without being dependent on other buggier functionality.

Not sure how good TFS is at merging but I'm sure you'll know in a few months :)

share|improve this answer
This is pretty close to how we are doing it where I work. If you only make sure to religiously merge from trunk to each working branch whenever changes make it into trunk, it works quite well. Also, look into setting up automated builds at the same time. Knowing that each branch (as stored in source control) is always in at least a buildable state makes things much easier. As for merging using Visual Studio's tools, it works well until you have hugely long lines with changes on both sides of the merge... – Michael Kjörling Sep 6 '11 at 12:52

We can't get by with a single development branch because we will want to merge to Main while other work is completed.

It sounds like you already know that multiple development branches must be created. Two probable scenarios come to mind:

  1. Each of the five developers are working on independent parts of the project (bug-fixing) - Make sure that an individual branch is created for each developer. This places the onus and responsibility onto each developer to make sure their set of changes does not conflict with anyone else's work. It is highly likely that one of your five developer will make a mistake. If/When that's the case, it doesn't make any sense for everyone else to be held up.
  2. Multiple feature developments - Regardless of the number of developers working on a particular feature/bug, these should be separated. An example of this being beneficial is that all code commits are part of the feature(s) being developed - there's no second-guessing involved.
share|improve this answer

Implied work branches with DVCS

We use Mercurial so there is the implied work branch on the developers dev box. Commit are always done to the local workspace. When a releasable piece of work is completed it is pushed up to the primary repo server where it is automatically built and tested.

We almost never create explicit branches, but then again our sprints are never more than 1 week long and are cards take no more than 1-2 days to complete.

Also, you can mitigate merge pain by threading in work from other parts of code or other projects so people aren't having to do difficult merges all the time.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.