Explained: Branching in Team Foundation Server

- J.D. Meier, Jason Taylor, Alex Mackman, Prashant Bansode

Applies To

  • Team Foundation Server
  • Visual Studio Team System

Summary

This guidance module explains the common scenarios and strategies for branching and merging your source control trees by using Team Foundation Server. This module serves as a reference point for additional modules used for the patterns & practices Visual Studio Team System Guidance (link).

Contents

  • Overview
  • Scenarios for Branching and Merging
  • Example Folders and Their Purpose
  • Example 1: Branch for Release
  • Example 2: Branch for Feature
  • Example 3: Branch for Maintenance
  • Example 4: Combined

Overview

You use branching to isolate parallel development efforts. For many simple scenarios, you don’t need to branch and labeling your builds is sufficient. Consider branching if you need isolation for parallel teams, to work on separate, but overlapping features, or to support a release.

Scenarios for Branching and Merging

The following are examples of when you might need to create branches and perform merges:
  • If you are having regular problems with broken builds, then a create development branch to isolate parallel development efforts.
  • If you have features that are causing stability issues among each other or teams causing stability among each other, then create separate feature or team branches beneath a development container folder in source control.

If you have one stream of development, or are performing incremental and continuous releases, you might not need to create branches unless you frequently experience breaking changes that are destabilizing development efforts.

Common Scenarios in Practice

The following are the most common branching scenarios in order of increasing complexity:
  • Scenario 1 – your team works only from the main source tree. In this case, you aren’t creating branches and you don’t need isolation. This scenario is generally for smaller or medium sized teams that don’t require isolation for teams or for features, and doesn’t need the isolation for releases.
  • Scenario 2 – your team creates branches for release. In this case, your team creates a branch to stabilize the release and then merges the release branch back into the main source tree after the software is released.
  • Scenario 3 – your team creates a branch to maintain an old build. In this case, you create a branch for your maintenance efforts, so that you do not destabilize your current production builds. You may or may not merge the maintenance branch back into the main tree. For example, you may work on a quick fix for a subset of customers that you either don’t want to add to the main build or you don’t want to add at this time.
  • Scenario 4 – your team creates branches by features and teams. In this case, you create a development branch, you perform work in the development branch, and then you merge back into your main source tree. The branch may be organized by features or by teams.
  • Scenario 5 – your team creates branches for features and teams, as well as for releases. You create a branch for parallel development. You can organize by features or teams. You branch from your main branch into your development branch and you perform integration builds into your main tree. You create a branch for your production releases and then merge these back into your main tree.

You may encounter one or more of these scenarios. Use these scenarios as a reference point to see what guidance may or may not apply to you.

Key Notes

  • Scenario 1 is generally a smaller team that doesn’t have to worry about isolation.
  • Scenario 2 is the next most common case where you need to create a branch to stabilize for a release.
  • Scenario 3 is a common case for teams who need to perform maintenance on released builds.
  • Scenario 4 is generally used by larger teams who have dedicated feature teams or discrete development teams working in isolation.
  • Scenario 5 is generally used by larger teams who not only have development teams working in isolation but also need to create a branch to stabilize for a release.

Example Folders and Their Purpose

The following folders are examples of folders you might create in Team Foundation Server source control when structuring your source tree for branching and merging scenarios:
  • Development (container or branch). Branched from Main and used to isolate active development.
  • Main. Contains your main source tree.
  • Production (branch). Branched from Main and contains the release you are currently locking down prior to release.
  • Maintenance (container ). This folder contains branches you have already shipped but now need to maintain for customers. Provides isolation from your active development occurring in your development branch.

Key Notes

  • Development. Branched from Main to provide isolated development.
  • Main. Contains your most recent development builds.
  • Production. Contains your release candidate. You work in this branch to prepare your software for release, while others continue to work in the Development branch working on new features.
  • Maintenance. As soon as you release your software, you create a Maintenance* folder and move your Production branch into it. You use it to perform maintenance work. Use labels to mark pre-maintenance builds you may want to return to.

Example 1: Branch for Release

This is a scenario 2 example where your team creates a branch to stabilize the release and then merges the release branch back into the main source tree after the software is released. The following is a physical view showing branching for releases.

Main 				-> Main integration branch
    Source
Production 			-> Release branch 
    Source

Example 2: Branch for Maintenance

This is a scenario 3 example, where you create a branch for your maintenance efforts, so that you do not destabilize your current production builds. The following is a physical view showing maintenance branches:

Main 			-> Main integration branch
    Source
Maintenance 		-> Maintenance branch container
    Release 1 		-> Maintenance branch
           Source		
    Release 2 		-> Maintenance branch
           Source

Example 3: Branch for Feature

This is a scenario 4 example, where you create a development branch, perform work in that branch and then merge back into your main source tree. You might organize your development branches by product features or by teams. The following is a physical view showing branching for development:

Development 				-> Feature branch container
       Feature A 			-> Feature branch	
              Source
       Feature B 			-> Feature branch
              Source
       Feature C 			-> Feature branch
              Source
Main 					-> Main Integration branch
       Source

Example 4: Combined

This is a scenario 5 example, showing how a large team may have branches for development, release and maintenance:
Development 				-> Feature Branch Container
      Feature A 			-> Feature Branch
            Source
      Feature B 			-> Feature Branch
            Source
      Feature C 			-> Feature Branch
            Source
Main 					-> Main Integration Branch
      Source
Production 				-> Release Branch 
      Source
Maintenance 				-> Maintenance Branch Container
      Release 1 			-> Maintenance Branch
           Source
Safe Keeping 				-> Safekeeping container (optional)
      Retired Release 1		        -> Branch
           Source
      Retired Release 2 		-> Branch
           Source

Additional Resources

Last edited Apr 4, 2007 at 11:13 PM by jtaylorsi, version 6

Comments

No comments yet.