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?
Best Answer
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 create 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 :)