Announcing Stack Overflow Documentation



Sign up and start helping → Learn more about Documentation →

Using TFS, when would you label your code and when would you branch?

Is there a concept of mainline/trunk in TFS?

share|improve this question

A label in TFS is a way of tagging a collection of files. The label contains a bunch of files and the version of the file. It is a very low cost way of marking which versions of files make up a build etc.

A branch can be thought of as a copy of the files (of a certain version) in a different directory in TFS (with TFS knowing that this is a branch and will remember what files and versions it was a branch of).

As Eric Sink says, a branch is like a puppy. It takes some care and feeding.

Personally, I label often but branch rarely. I create a label for every build, but only branch when I know that I need to work on a historical version or that I need to work in isolation from the main line of code. You can create a branch from any point in time (and also a label) so that works well and means that we don't have branches lying around that are not being used.

Hope that helps,


share|improve this answer

In any VCS, one usually tags when you want a snapshot of the code, to be kept as reference for the future. You branch when you want to develop a new feature, without disturbing the current code.

share|improve this answer
+1 purely for pithiness :) – Brian Lacy Nov 20 '13 at 15:55

Andrew claims that labeling is lazier than branching; it's actually more efficient in most cases, not lazy. Labeling can allow users to grab a project at any point in time, keep a history of files changed for a version or build, and branch off of/work with the code at any point and later merge back into the main branch. Instead of what Andrew said, you're advised to only branch when more than one set of binaries is desired- when QC and Dev development are going on simultaneously or when you need to apply a hotfix to an old version, for example.

share|improve this answer

I always see labels as the lazy man's branch. If you are going to do something so significant that it requires a full-source label then it is probably best to denote this with a branch so that all tasks associated with that effort are in an organized place with only the effected code.

Branching is very powerful however and something worth learning about. TFS is not the best source control but it is not the worst either. TFS does support the concept of a trunk from which all branches sprout as well.

I would recommend this as a good place to read up on best practices - at least as far as TFS is concerned.

share|improve this answer
With respect, that is very poor advice since labels and branches do two very different things. If someone misused labels when they were trying to accomplish branching, I would agree, but labels do exactly as the name implies: they mark and group a particular set of files, which is useful for reasons that do not involve branching. If you work in a situation where you have multiple release stages, the utility (and difference) becomes very obvious. Hence, I have downvoted. – McGuireV10 Jun 22 '12 at 12:30
@McGuireV10 I agree with respect to Andrew Hare's use of the phrase "I always see labels as..." -- in that there is absolutely a strong "proper" use case for labels. Having said that -- coming from a Subversion background and then making my way through the distributed VCS world and back to TFS (not by choice, per se) -- for Subversion converts labels will seem like a weak substitute for tagging, and that may be why some folks mix up their use of labels and branching. Of course, for someone moving from TFS to SVN, tagging will seem like a pretty heavy-handed substitute for labels. :) – Brian Lacy Nov 20 '13 at 14:54

Your Answer

