The answer to this question is, you should not branch!! For many simple scenarios, you don't need to branch and labeling your builds is sufficient. Because with branching merging comes into the picture, the complexity of branching increases the pain of merging exponentially. Said that, you should branch only when you have to isolate parallel development efforts. Here are few common scenarios which gives insight as to when and how you should branch.
- If you are working on one release at a time, then you just don't need to branch, just work from your main trunk.
- If you want parallel development while you prepare for intermediate release and need to stabilize the release build, then you need to branch the release source code. Do testing / bug fixing on the release branch and parallel development on the main trunk. Once the release is done, you might / or might not want to merge the bug fixes to the main trunk.
- If you have to make a patch or hotfix on an old release with parallel development for a new release, then, you branch the old release. Do testing / bug fixing on the patch / hotfix release and parallel development on the main trunk. Once the patch or hotfix is done, you might or might not want to merge the bug fixes to the main trunk
- If you are having regular problems with broken builds, then a create development branch to isolate parallel development efforts. Merge the development regularly with the main trunk, which can be used for stabilized build.
- If you have features which can be worked in parallel, but might cause stability among each other, then branch the main trunk for each feature development. Merge the feature branches regularly into the main branch and reverse merge for features to share code. The main branch is used for stabilized build.
There is a good document - Explained: Branching in Team Foundation Server, which gives insight on the branching strategy.
So no more, To branch or not to branch dilemma.
~Later