How to Avoid Working on the Wrong Branch

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 :)

TFS? Run for the hills! Move off as quickly as you can. It does a lot of different things but none of them as good as the available best of breed tools.

But seriously:

Once you have a decent version control system (SVN, GIT, etc.) I'd recommend setting up rules for branch management, e.g. when to create branches, for what, when to merge, who, and a lot more.

Until recently we used a single branch for new development ('trunk'). For a release we would create a branch off trunk. Final QA would be done in that branch and once completed we would release (we are on monthly releases).

We have switched to the concept of 'no junk in the trunk' to reduce the schedule risk. This concept basically contains a rule by which you'd create branches for development work separate from trunk. For example you could have a separate branch for a feature, for a small development team or similar. We use 'epics' to describe a small feature or releasable part of a feature and create a branch for each epic. At least once a day all changes from trunk are merged into the epic branch. Key is good merge support by version control or a separate tool (e.g. three way merge). QA for the epic would be done on the epic branch. Once passed the epic branch would be merged into trunk and an integration test be run. We still have branches for releases.

With the epic branches we have substantially reduced the schedule risk as we are now in a position to release out of trunk and include all epics that were successfully merged into trunk. Epics that are not complete miss the bus and will make the next release (next month).

This of course may work only in our environment. Very likely you will have factors different from ours that will influence what the best choices are for branch management.

For example if you have a team with a lot of people working remotely and not always being connected to the version control server, then you would want to use a version control system that supports a distributed model. GIT and a few others would fall into this category. TFS to the best of my knowledge requires a connection to the server to just make files writable (fixed in version 2010?).

I hope I was able to show that there is not "one size fits all". Start with your processes in particular branch management, determine the requirements and finally select the tool that is the best match for your needs. Maybe it is TFS, maybe not.