BRANCHING

Quick Start

Basic Branch Plan

Below is a basic plan that enables concurrent development for your next release, a stable main branch for testing and a release branch for any ship blocking bug fixes. Consider when

Single Team Branching Model

Allows an organization to improve their engineering practices, by focusing on the flow of source code throughout the development process, using very simple branching model.
V1.1 (start) DEV V1.1 FT3 V1.2

SC
Source Structure $ WoodGroveBanking

Co m EN mon

AR

IOS

Branch

Dev

You have a single major release that is shipped (i.e. a single release vehicle) to customers. Your servicing model is to have customers upgrade to the next major release. Any fixes shipped from the release branch will include all previous fixes from that branch.
MAIN

V1.2

+
Main

Source

RI

FI

FI

RI

FI

V1.1

Source

flow of merges (changes)

V1.0 Production

V1.1 (bug f ix)

DEVELOPMENT

Development

It is imperative that the MAIN branch be stable with the latest customer-ready version

Branch

MAIN
flow of merges (changes)

Concurrent Hot Fix, Service Pack and V.Next Branching Model

Production / Release

DEV

Source Structure $ WoodGroveBanking

Branch

DEV-1 2
Branch

Dev

Branch

Branch

FI

Standard Branch Plan

Consider when

RELEASE

This scenario allows organizations to service a released product with hot fixes, with a cumulative service pack that includes all approved hot fixes, and the ability to work simultaneously on the next version of the product.

Dev-1

R1 (SP) R2 (SP) 6
Branch

+ +

Source

Dev-2
Source

MAIN

Main

The Standard branch plan introduces a new release branch to support an additional release vehicle. Most organizations will call this a servicing branch to enable development of Hotfixes and Service packs.

When MAIN is ready to release, create the SERVICE PACK, HOT FIX, and RELEASE branches at the same time. The RTM branch is a read-only copy of what was released

+
V1

Source

SERVICE PACK

Hotfix

You have multiple ship vehicles (e.g. major release and additional service packs for that release). You want to enable concurrent development of service pack and next version products. You have any compliance requirements that require you to have an accurate snapshot of your sources at release time.
flow of merges (changes)

Branch

Branch

+
RTM

Source

R1 (SP0)

R1 (SP1) 7

R2 (SP0)

HOT FIX

4
Branch Branch

Source

Branch

+
V2

Service Pack

Source

R1 (SP0) RTM 5

R1 (SP1) 8

R2 (SP0)

DEVELOPMENT
Branch

Development
V1.1 FT3 (start) DEV FT3 V1.1 FT3

Multi Feature Teams Scenario Branching Model

In the Multi Feature Teams scenario, The DEV now becomes a container node which contains a group of branches where each branch is dedicated for a particular feature. The MAIN is still a single branch as alike other scenarios.
Source Structure
RI

MAIN
V1.1 FT2 (start) V1.1 FT2

Branch

$ WoodGroveBanking

flow of merges (changes)

Production / Release

DEV FT2

Dev

BM

V1.1 FT1 (start)

+ + +

Dev-1

SERVICE PACK
Branch

V1.1 FT1

+ Source
Dev-2

FI

DEV FT1

RI

Dev-3

Branch

Branch

Branch

V1.1 FT1

V1.1 Golden

FI

RI

Main Source

RELEASE
MAIN

Branch

Advanced Branch Plan

Branch

V1.0

This scenario is time intensive and involves quite a number of people.

MAIN
FEATURE 2

RI

Production

VSS

V1.0.1

V1.1 (Release)

Source

PRODUCTION
V1.0 (hotf ix)

flow of merges (changes)

The Advanced plan is for products that must support many release vehicles and servicing scenarios. The plan allows for concurrent development of a major release, service packs, hot fixes and next version work.

Branch

Production / Release

Team, Feature, Release Isolation Branching Model

In this scenario branching is used as a policy for code promotions and each branch has an owner. The owner of the branch has to ensure that the policy is enforced (for example code reviews have been completed).
BRANCHES

Source Structure $ WoodGroveBanking

RI

Dev

SERVICE PACK

Feature1

TEAM 2

Branch

+ +

Source

Feature2
Source

FEATURE 1
Branch

HOT FIX

Main Production
Other

Development
Feature Release

Main

Source

Branch

RI

Production

TEAM 1

Release1

Branch

RELEASE
MAIN
1

RI

+
Team

Source

Branching Node

Milestone
Build

KEYS

Label

Team1

Branch

FI

Forward Integration

Changeset

Vocabulary

+ +

Source

DEVELOPMENT branches MAIN branch SERVICE PACK (SP) HOTFIX RELEASE branch FORWARD INTEGRATE (FI) REVERSE INTEGRATE (RI) RELEASE VEHICLE

Changes for next version work. This branch is the junction branch between the development and release branches, representing a stable snapshot of the product that can be shared with QA or external teams. A collection of hotfixes and features targeting a previous product release. A change to fix a specific customer blocking bug or service disruption. A branch where ship stopping bug fixes are made before major product release. After product release this branch usually becomes read-only. Merges from parent to child branches. Merges from child to parent branches. How your product gets to your customer (e.g. major release, hotfixes and/or service packs).
RELEASE 1

RI Reverse Integration

BM

Baseless Merge

Team2

Source

For more information, refer to http://tfsbranchingguideiii.codeplex.com

Team Foundation Server (TFS) Branching Guidance 2010 Visual Studio ALM Rangers
2010-03-20

Branches are now First Class Objects

New branch icon emphasizes first class branch objects

Reparenting Branches

Used to establish parent-child relationship between baseless merged branches as well as to alter existing branches' parent-child relationship in a branch hierarchy. To "reverse" an existing parent-child relationship, the child branch will need to be disconnected from the parent branch via "No parent" option, and then re-parent the former parent branch to the former child branch. Select the relevant branch, i.e. Feature 1, and select Reparent Branch from the context menu.

Branches enable features such as: The ability to store properties like the owner and a comment to each branch Viewing the branch hierarchy graphically Tracking where and when changesets have been merged

Branch Visualization

Project Collection Build Service Accounts

Project Administrators

Project Collection Service Accounts

Project Collection Administrators

Contributors

Permissions

Default Permissions = Allow Read Check Out Check In Label Lock Revise other users changes Unlock other users changes Undo other users changes Administer labels Manage permissions Merge Manage Branch

Builders

Readers

Select the relevant branch, i.e. Main, from the Branching and Merging context menu and select View Hierarchy option to obtain a logical and visual view.

You can drag from Dev (33) to Feature1, to perform a drag and drop merge instruction.

Changeset Tracking

Select the relevant branch, i.e. Main in the Source Explorer and select Properties from the context menu

Branch Properties
Team Foundation Server (TFS) Branching Guidance 2010 Visual Studio ALM Rangers