Guia Basica de Braching

2012
ALM Rangers
VISUAL STUDIO BRANCHING AND MERGING GUIDE
October 17, 2012
This content was created by the Visual Studio ALM Rangers, a special group with members from the Visual Studio Product Team,
Microsoft Services, Microsoft Most Valuable Professionals (MVPs) and Visual Studio Community Leads.
ALM Rangers - Visual Studio Branching and Merging Guide
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the
date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a
commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of
publication.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO
THE INFORMATION IN THIS DOCUMENT.
Microsoft grants you a license to this document under the terms of the Creative Commons Attribution 3.0 License. All other rights
are reserved.
 2007 - 2012 Microsoft Corporation.
Microsoft, Active Directory, Excel, Internet Explorer, SQL Server, Visual Studio, and Windows are trademarks of the Microsoft group of
companies.
All other trademarks are property of their respective owners.
Page 2 of 32
Table of Contents
Introduction....................................................................................................................................................................................................................... 4
Visual Studio ALM Rangers .................................................................................................................................................................................... 4
Contributors ................................................................................................................................................................................................................. 4
What’s New .................................................................................................................................................................................................................. 4
Branching ........................................................................................................................................................................................................................... 5
Branching Concepts .................................................................................................................................................................................................. 5
Branch Types ................................................................................................................................................................................................................ 8
Branching Plans ........................................................................................................................................................................................................ 10
Visualizing Branch Plans ........................................................................................................................................................................................ 16
Merging ............................................................................................................................................................................................................................ 17
Tracking and Administration ............................................................................................................................................................................... 17
Visual Studio 2012 Merging Enhancements ................................................................................................................................................. 18
Baseless Merging ..................................................................................................................................................................................................... 19
Frequently Asked Questions (FAQ) and Answers ............................................................................................................................................. 21
Appendix .......................................................................................................................................................................................................................... 32
Additional Resources & References ................................................................................................................................................................. 32
Other ALM Rangers Resources ........................................................................................................................................................................... 32
Figures Reference .................................................................................................................................................................................................... 32
Tables Reference ...................................................................................................................................................................................................... 32
Page 3 of 32
Introduction
This guide aims to provide insightful and practical guidance around branching and merging with Team Foundation
Server. Branching and merging of software is a vast topic. It is imperative to realize that every organization is different,
and there is ‘no one size fits all’ branching strategy. These guidelines are meant to serve as a starting point for your
planning, but you may find that deviating in certain circumstances. In this guidance, the focus is primarily on practical
and real world scenarios of branching that you can apply immediately. We avoid discussing the mechanics of branching
but rather focus on best practices and real world examples of patterns that work for many of the business cases we
have seen. This guide is supplemented by the Branching and Merging Version Control focused Guide, Hands-on
Lab activities, and updated branch diagrams.
For easy re-use and enhancement, we provide the Branching and Merging Guide - Illustrations.pptx
template.
Note
Visual Studio ALM Rangers

The Visual Studio ALM Rangers are a special group with members from the Visual Studio Product group, Microsoft
Services, Microsoft Most Valuable Professionals (MVP) and Visual Studio Community Leads. Their mission is to provide
1
out-of-band solutions to missing features and guidance. A growing Rangers Index is available online .
Contributors
Anil Chandra Lingam, Bijan Javidi, Bill Heys, Brian Blackman, Brian Minisi, Clementino de Mendonca, Daniel Manson,
Jahangeer Mohammed, Jansson Lennart, Jens Suessmeyer, Krithika Sambamoorthy, Matthew Mitrik, Mike Fourie,
Micheal Learned, Neno Loje, Oliver Hilgers, Taavi Koosaar, Tony Whitter, Willy-Peter Schaub
What’s New
 New recommendations around our existing branching plans, as well as adding new branching plans
 Merge improvements in Visual Studio 2012
 Visualizing Branch Plans
 Tracking and Administering merge debt
 Different scenarios for baseless merging are discussed
 This guide is supplemented by
o Visual Studio Advanced Version Control guideHands-on Labs and Quick Reference guides
2
Please consult the Team Foundation Build Customization Guide , in particular Branching Process
Templates section, which discusses branching strategies in respect to Team Foundation Build.
Note
1
http://aka.ms/vsarindex
2
http://go.microsoft.com/fwlink/?LinkID=230938
Page 4 of 32
Branching
Vocabulary
Terminologies may vary in your organization so some translation may be required as tabled below
Term Description
Development Branch Changes for next version work

Forward Integrate (FI) Merges from parent to child branches
Hot Fix A change to fix a specific customer-blocking bug or service disruption
Main Branch This branch is the junction branch between the development and release branches. This
branch should represent a stable snapshot of the product that can be shared with QA or
external teams
Release Branch A branch where ship stopping bug fixes are made before major product release. After product
release this branch may become read-only based on your process
Release Vehicle How your product gets to your customer (e.g. major release, Hotfixes and/or service packs).
Reverse Integrate (RI) Merges from child to parent branches
Service Pack (SP) A collection of Hotfixes and features targeting a previous product release
Table 1 – Branching Vocabulary
Branching Concepts
“Your branch distance from main is equal to your level of insanity” - anonymous
Branching enables parallel development by providing each development activity a self-contained snapshot of needed
sources, tools, external dependencies and process automation. Having more branches increases complexity and merge
costs. Nevertheless, there are several scenarios where you will need to consider multiple branches to maintain a
required development velocity. Whether you branch to temporarily stabilize a breaking change, develop a feature or
jumpstart development on a future version, you should consider the following:
 Branch from a parent with the latest changes (usually MAIN or another DEV branch).
 Branch everything you require to develop in parallel, typically this may mean branching the entire parent.
 Merge from the parent branch (FI) frequently, at least every day if possible if active changes are taking place.
 Ensure you build and run sufficient BVT’s to measure the stability of the branch.
 For stabilization changes, make your changes, build and pass all BVTs before merging (RI) the change and
supporting changes to the parent.
 A merge (RI) to MAIN is treated like a “feature release” to peer development teams. Once the feature branch
merges (RI), other teams will use that version of the feature until the next merge (RI).
 When MAIN branches for release (current version), servicing of final ship-stopping bug fixes should be made in
the RELEASE branch. The feature branch is just for next version work. In this example when MAIN branches for
release all DEV branches can begin next version work.
Avoiding Branching
The bar for creating a branch should be set fairly high to avoid the inevitable associated costs. Consider the following
before creating a branch for temporary development work
Page 5 of 32
1. Can you use a shelveset? Frequently developers just want a way to save or share changes. A shelveset
accomplishes both of these tasks by saving the changes in the Team Foundation Server database but not
committing them to the branch.
2. Is there another work item you should be working on? Sometimes other work is not visible to the individual
engineer.
3. Work in the “next version” branch mentioned above if the change is approved for next version release.
4. Is the branch needed now, or can it rather be created at a later date, perhaps from a changeset version.
Always make sure you can adequately describe the value a branch is giving your organization; otherwise perhaps the
branch is not needed.
Branching with Labels

Organizations that need a good deal of stability should consider creating branches to capture specific versions of code
that went into a release. Utilizing this type of branching strategy makes it relatively easy for a developer to be able to
pull down a specific version of code and perform maintenance on that version. Creating a branch from specific versions
of source allows the creation of branches for maintenance as needed instead of as a side-effect of every release. When
branching by version using Team Foundation Server it’s important to recognize the value that labels provide.
Labels in Team Foundation Server are a powerful tool that allow for a development team to be able to quickly identify
files at specific version levels. Utilizing labeling as part of a branching strategy allows developers to be able to isolate
code from subsequent changes that may have happened in the source control system. For example if maintenance is
needed on a specific version, a branch can be created at any time in the future based on a label. This can lead to a
cleaner version control folder structure as new folders are only created as needed.
It’s important to caution against the over-use of labels given that:
 Team Foundation Server does not retain a history of changes made to the label.
 Given certain permissions, labels might be deleted or otherwise invalidated by changes, and there is no way of
auditing those changes.
 There can be contention for a given label if more than more person wants to use and modify the label or the
files contained in the label.
 As such, labels should only be used in cases where a snapshot of sources is needed and if it’s possible to
guarantee via permissions that the label won’t be changed.
Building Branches
It can be helpful to name builds for branches so as to easily identify the builds and output associated thereof, e.g.
 DEV_ProductName_buildnumber
 REL_ProductName_buildnumber
 FEA_ProductName_FeatureName_buildnumber
The build information can be added to build artefacts, e.g. Assembly Information attribute of an assembly to directly
link the artefact to a specific build. This traceability can be helpful if you have multiple branches and build agents.
Permissions
From Team Foundation Server you have two permissions related to branching and merging
 Manage Branch
 Merge
These two permissions allow teams to designate certain individuals to be responsible for creating new branches, while
Page 6 of 32
others can be responsible for merging code between branches, while most developers will be restricted to working only
on certain branches.
Branch Permissions
Users require Manage Branch permission on a given path in order to:
 Convert folders to branches
 Convert branches back to folders
 Update metadata for a branch, such as owner, description, etc.
 Create new child branches from a given parent branch
 Change the relationships between branches with merge relationships (i.e. re-parenting branches)
Manage Branch permission only applies to branches. Users are not prevented from branching ordinary folders for
which this permission has been denied. Manage Branch permission is scoped to a specific path. Branches can still be
organized in folders. Thus Manage Branch permission enables a team to arrange their branches such that some
branches can be further branched by users but others cannot.
For example, if a team could deny Contributors Manage Branch permission for all branches organized under the paths:
$/<TeamProject>/Main and $/<TeamProject>/Releases, but allow Contributors the Manage Branch permission for
feature branches organized under the path $/<TeamProject>/Development. With these permissions, members of the
Team Foundation Server Contributors group can create child branches for development (from existing feature
branches), but cannot create new branches from existing release branches or from the Main branch.
Merge Permission
Users require Merge permission in order to Pend merge operations on branches, folders, and files under a specified
path. Merge permission is required for the target path of a merge operation. There is no permission to prevent a
particular branch or folder from being merged to another path. Merge permission is not limited to branches – it can be
applied to folders and branches under a given path.
Page 7 of 32
Branch Types
There are three general branch types, DEVELOPMENT, MAIN and RELEASE. Regardless of branch type, you should apply
the following considerations to all branches
 Build daily to give the team a daily cadence to work toward.
 Implement continuous integration builds to immediately identify quality issues
 Code flow, the movement of changes between child and parent branches, is a concept all team members must
consider and understand.
The following table lists additional considerations and comments for each type.
Attributes Comments
MAIN MAIN is the junction between DEVELOPMENT and
 Every branch you intend to merge with should have a natural RELEASE branches. Changes in MAIN will probably
merge (RI) path back to MAIN (i.e. no baseless merges). merge (FI) into DEVELOPMENT, so it is critical that
 Breaks in MAIN need to be fixed immediately. builds from MAIN remain high quality. At
 No direct check-ins to MAIN branch; only build and BVT fixes minimum this means MAIN must remain buildable
are a good practice. and pass all BVT’s.
 Successful MAIN build indicates child DEVELOPMENT
As the number of DEVELOPMENT branches
branches should merge (FI) from MAIN.
increase, the need to merge (FI) following each
 QA teams should be able to pick up any MAIN build for
successful MAIN build increases.
testing.
DEVELOPMENT A self-contained branch effectively enables each
Before creating a DEVELOPMENT branch, make sure you can do development activity to proceed at its own pace,
the following: without taking any dependency on another. It
follows that these branches are allowed to diverge
 Select a parent branch – if your changes are focused on your
their respective sources along the particular
next product release then the parent branch should be MAIN.
development activity they are involved with –
 Branch from a recent known good state of the parent – start
fixing a bug, implementing a feature, or stabilizing
your branch from the latest successful build of the parent
a breaking change.
branch. On day one of your DEVELOPMENT branch it should
be in the same state as its parent (i.e. build and pass BVTs
successfully).
 Merge (FI) frequently – your goal should be to be no more
than 1-2 days out of sync with MAIN. This will help reduce
the complexity of “big bang” type merges. Ideally you should
merge (FI) every time the parent branch builds and passes
BVTs.
 Merge (RI) from child to parent based on quality. Minimum
merge (RI) requirements are
o Be in sync with parent branch
o Build successfully
RELEASE Your release branch plan should be built around
A successful release branch strategy enables the following 3 your software release vehicles. A release vehicle is
scenarios. how your software is delivered to your customer.
The most common release vehicles are the major
1. Developers only need to check in once based on which
release, Hotfix and service pack. In a software plus
release vehicle the change is for (i.e. Hotfixes go into the
services scenario the names may be different
product HOTFIX branch).
however and the release may be more frequent.
2. No need for baseless merges. Create a natural merge path
back to MAIN by creating a hierarchal branch structure based
Page 8 of 32
Attributes Comments
on your release vehicles.
3. Reduce risk of regressions. By creating a parent/child branch
relationship between MAINSP and HOTFIX branches
changes are naturally merged into future release (i.e. Hotfixes
merge into the SP branch on their way to MAIN) reducing risk
of bug regressions in future releases.
Table 2 – Branch Type Considerations
Page 9 of 32
Branching Plans
“Save your creativity for your product… not the branch plan.” – Anonymous
The elements of the branching plans introduced in this section are typically additive; starting with the Basic plan will
allow you to transition to the Standard and then Advanced plans if your branching requirements become more
complex. There are two common reasons for increasing branch numbers and hence complexity.
1. The need for additional release vehicles (i.e. Service Packs and Hotfixes) will require a branch plan that supports
concurrent development for each of these.
2. Additional development requirements such as needing to isolate features into their own branches.
The goal of the branch plans presented is to cover most customer branching scenarios. Please post your scenarios not
covered to the community discussion associated with this document at http://vsarbranchingguide.codeplex.com. Our
hope is to leverage the CodePlex community to cover alternative (but still valid) branch plans.
Page 10 of 32
Basic Branch Plan
The basic branch plan with a MAIN, DEV, and RELEASE branch enables concurrent development for your next release, a
stable MAIN branch for testing and a RELEASE branch for any ship blocking bug fixes. Multiple development areas are
supported by creating additional development branches from MAIN. These are peers to each other and children of
MAIN.
Additional releases are supported by creating release branches for each product release. Each release branch is a child
of MAIN and a peer to each other (e.g. release 2.0 branch is peer to release 3.0 and both are children of MAIN). If
supporting only a single release in production at a time, you may consider a single release branch, and make bug fixes
directly on this branch. Once the RELEASE branch is created MAIN and the development branches can start taking
changes approved for the next product release. An even simpler version of this plan for smaller teams might only
include a MAIN and RELEASE branch. Consider this if the isolation required only required two branches such as for
smaller teams and projects.
Figure 1 – Basic Branch Plan
Usage Scenarios Considerations

1. You have a single major DEVELOPMENT (DEV) branches for next version work.
release (i.e. a single
a. Work in DEV branches can be isolated by feature, organization, or temporary
release vehicle) that is
collaboration.
shipped to customers.
b. Each DEV branch should be a full branch of MAIN.
2. Your servicing model is to
c. DEV branches should build and run Build Verification Tests (BVTs) the same
have customers upgrade
way as MAIN.
to the next major release.
d. Forward Integrate frequently from MAIN to DEV if changes are happening
a. You are not
directly on MAIN.
supporting
e. Reverse Integrate from DEV to MAIN based on some objective team criteria
multiple versions
(e.g. internal quality gates, end of sprint, etc.).
in production at
once. RELEASE branch where you ship your major release from.
3. Any fixes shipped from the a. RELEASE is a child branch of MAIN.
release branch will include b. Your major product releases from the RELEASE branch and then RELEASE
all previous fixes from that branch access permissions may be set to read only to prevent changes from
branch. happening directly on the branch.
c. Changes from the RELEASE branch merge (RI) to MAIN. This merge is one
way. Once the release branch is created, MAIN may be taking changes for
next version work not approved for the release branch
d. Create new RELEASE branches for subsequent major releases if you require
that level of isolation.
Table 3 – Basic Branch Plan Summary
Page 11 of 32
Standard Branch Plan
As you add additional release vehicles from the basic plan, you may need to create additional branches in the
production/release area to enable concurrent development. The Standard branch plan below introduces a new release
branch to support an additional release vehicle. Most organizations will call this a servicing branch to enable
development of bug fixes and Service Packs. You can be doing next version development in DEV and MAIN, and
support Service Pack development in the SERVICE PACK branch, as well as do emergency Hotfixes directly on the
release branch. Once the next version is ready for release you can choose to create new SERVICE PACK and RELEASE
branches. This can give you a high level of parallel development.
Figure 2 – Standard Branch Plan

All of the guidance from the Basic plan applies to the Standard plan.
Usage Scenarios Considerations

1. You have multiple ship vehicles 1. RELEASE branches for release safekeeping and Service Pack work
(e.g. major release and additional 2. RELEASE tree (i.e. SP and RELEASE) are branched from MAIN at the same
service packs for that release). time to create MAINSPRELEASE parent/child relationship.
2. You want to enable concurrent 3. Product releases from the RELEASE branch and then that branch can be
development of service pack and changed to read only.
next version products. 4. Servicing changes are checked into the Service Pack (SP) branch.
3. You have any compliance 5. Changes in SP branches merge one-way to MAIN (SPMAIN).
requirements that require you to 6. Ship stopping bug fixes checked into the release branch should RI merge
have an accurate snapshot of back to MAIN through the SP branch (SPMAIN).
your sources at release time. 7. Duplicate RELEASE tree plan for subsequent major releases if you require
that type of isolation.
Table 4 – Standard Branch Plan Summary
Page 12 of 32
Advanced Branch Plan
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, Hotfixes and next version work. By adding a Hotfix branch
between the Service Pack and Release branches, you add another level of parallel development as you may develop
and release critical bug fixes via the Hotfix branch while doing longer term feature development, and less critical bug
fixes on the Service Pack branch. You may create new release branches, as well as retire or delete old release branches,
and you can also leverage security settings to ensure release branches are toggled to read only. This plan also allows
you to support multiple releases in production at one time due to having multiple release branches. Keep in mind that
you could also create additional DEV branches to support additional isolation on the development side as needed.
Figure 3 – Advanced Branch Plan

All of the guidance from the Basic and Standard plans apply to the Advanced plan.
Additional Considerations
1. RELEASE branches for release safekeeping, HOTFIX and Service Pack work
2. RELEASE tree (i.e. SP, HOTFIX, and RELEASE) are branched from MAIN at the same time to create
MAINSPHOTFIXRELEASE parent/child relationship.
3. After creating the RELEASE tree make any final ship stopping bug fixes in the RELEASE branch. Produce the build
you will release from the RELEASE branch. After product release update the access permission in the RELEASE
branch to read only if desired. This will ensure that you have the precise set of sources that made the shipping
version of your product, and helps stop accidental changes from happening on a release branch.
4. Check-in based on which release the change applies to (e.g. Hotfixes are checked into the HOTFIX branch).
Maintenance of additional branches is expense so try to consolidate hot fixes for a single release in the HOTFIX
branch associated with a particular release. If a customer specific hot fix is required then branch just that single
component into a customer specific HOTFIX branch. A separate customer specific HOTFIX branch should be very
unusual.
5. Changes in HOTFIX and SP branches RI merge one-way through intermediate branches to MAIN
(HOTFIXSPMAIN).
6. Since hot fixes merge from the HOTFIX branch to the SP branch any release from SP would include all release hot
fixes + any changes made directly in the SP branch. Duplicate RELEASE branch plan for subsequent major
releases.
Table 5 – Advanced Plan Summary
The plans above cover the majority of software development activities. Using these plans as a base will enable your
teams to spend more time on developing high-quality code and assure that each branch has a specific role. The
additional content below may help you determine where to deviate from the plan above.
Page 13 of 32
Code Promotion Branch Plan
The code promotion is a plan that promotes versions of the code base to new levels as they become more stable.
Other version control systems have implemented similar techniques with the use of file attributes that indicate what
promotion level a file is in. Consider the diagramming model below where as the code in Main becomes stable, we will
promote the code base to the testing branch (sometimes this is referred to the QA branch). Full regression tests take
place on the testing branch, and additional bug fixes may occur. During this time new features may be developed in
the Main (which may be called Dev.) branch. Once the code is ready for release in the testing branch, it is merged into
the production branch. Final QA certification and testing can take place in the production branch. You may also
restrict permissions to only a few users on this branch to isolate risk, and once your readiness criteria are met you can
produce a build for release.
You may do active development on a future release in the Main branch, and also be making changes such as bug fixes
in the currently planned release in the testing branch and applying those changes via merging to both the production
branch as well as the main (development) branch if necessary. This allows development on the next version, while
stabilizing and preparing for a release. As with all branching plans, additional branches can be created if necessary. In
the scenario where you are maintaining only one version in production, the code promotion plan can work well as it
promotes parallel development and involves no “code freezes”.
You might consider creating branches that match your various deployment environments. However, keep in mind that
you may deploy the applications from the various branches to many actual deployment environments such as by using
the production branch build to deploy to one or more staging environments, and then eventually just move the
binaries into the real production environment once the final sign off has occurred. In other words, the code promotion
branches may match your various deployment environments, but are not required to do so. Having binaries move
through various levels of your deployment environments without rebuilding the sources removes redundancy and
ensures you are deploying what you are testing. This means from a branching to deployment environment relationship
perspective we have a 1: Many relationship that is possible. You may create more or less branches based on the level
of isolation you need for your specific scenario.
Figure 4 – Code Promotion Plan
Usage Scenarios
1. You have a single major release that is running in production.
2. You have long running testing lifecycles.
3. You wish to match your branches to your various deployment environments (not required).
4. You want to avoid code freezes, and still have isolation for your planned release.
Table 6 – Code Promotion Branch Plan Summary
Page 14 of 32
Branch by Feature Plan
On many software projects you may have clearly defined features you wish to implement in your product. There may
even be separate dedicated teams that are developing various features that all roll into a product. When you have this
clear isolation in your process, you may consider the branch by feature branching plan. Branching by feature can also
be a logical branch plan for large products that inherently have many features and various teams working on the
product. The idea with this plan is you can isolate each feature in its own branch which can give you a lot of flexibility
in terms of when a release is moved into production as well as help prevent situations where a branch needs “cherry-
picked” for features that are ready for production whereas other features are not ready. You merge the features into
main as they become stable enough for release. You may then delete the feature branches, and create new feature
branches as necessary.
As show in the diagram below, when a feature is stable, and ready to be promoted to main you can forward integrate a
merge from main to your release branch to obtain other features that have been integrated previously. You can then
stabilize on your release branch with working out any potential conflicts, and reverse integrate back to main your
feature. This will create a single changeset in main with your changes on the release branch, and this can easily be
rolled back if necessary.
Figure 5 – Branch by Feature Plan

When working with a feature branching strategy keep in mind that while other features are being merged into main,
you are introducing possible complexity and merge conflicts with the feature branches that are under development as
they drift away more and more from the original base in main as time goes on. A feature branch doesn’t have to be
complete before taking merges from main. In fact you should consider performing frequent forward integration
merges from main to your release branches to keep the integration of changes to be smaller in size, and thus less
complex. As an example consider if feature 2 in our diagram was under development, and feature 3 was recently
merged to main as complete. You could take a merge from main to the branch for feature 2, which would include the
recently released feature 3 changes. These changes can be stabilized in your feature 2 branch, and may even help you
avoid “reinventing the wheel” in some scenarios in your feature branch. If possible keep the life of your feature
development short, and integrate with main frequently.
Usage Scenarios
1. You have many concurrent features being developed in parallel.
2. You have clearly isolated features.
3. You have a large product with many features being developed that need isolation.
4. You have features being developed in parallel that are not necessarily on the same release cycle.
5. You need the ability to easily rollback features from a release.
Table 7 – Branch by Feature Plan Summary
Page 15 of 32
Visualizing Branch Plans
Many a whiteboard session has been had in teams where the same branch plan has been drawn in a different manner.
It is helpful if you standardize on a visualization within your team so that you can all clearly interpret the current areas
of code churn and delivery vehicles. Here are three common visualizations showing the same plan.
Name Diagram
Horizontal Timeline
This is the most common visualization
and provides a clear view of structure
and milestones. It can often become
cluttered though and some people do
not always see the code flow paths.
Figure 6 – Horizontal Timeline
Vertical Hierarchy
This is the view presented by Team
Foundation Server. It is a fairly basic
generation and provides a clear view
of code flow but little milestone
information.
Figure 7 – Vertical Hierarchy
Swimlanes
Swimlanes provide a clear view of
milestones and code flow paths. They
are particularly beneficial for advanced
and feature branch plans.
Figure 8 – Swimlanes
Table 8 – Branch Visualization Summary
Page 16 of 32
Merging
Tracking and Administration
Tracking and administration of changesets and defects is the highest cost associated with creating additional branches.
It is critical that the team remain on top of the merge ‘debt’ in their branch plan and instill processes to measure and
address this debt.
If you have a basic branch plan like the one

illustrated on the right, then keeping track
of merge debt is easy.
All you do in this case is ensure that any
fixes are merged through main and into Dev
where they can be integrated with the
upcoming functionality.
There will be little need to change any out-
the-box process templates or create any
automation to report debt. The standard
Visual Studio IDE features can be used to
administer this scenario.
Figure 9 – Tracking basic merge debt
In the advanced branch shown to the left,

REL A is in production, while a service pack
is being developed in SER A. REL B1 is also
with the cusomter for early industry testing
and SER B is staking feedback from REL B1
as well as implementing new functionality
which will be merged with changes coming
from fixes to REL A and the service pack
features in SER A before being branched
and delivered as REL B2. While this is all
happening, anything that merges through
Main will need to be forward integrated into
the feature branch FEA 1 which will ship to
the customer some time as an unsupported
release before being reverse integrated to
main at a later date for formal production
release. This level of complexity can not be
managed without some level of automation
or changes to process templates.
Figure 10 – Tracking basic merge debt
Table 9 – Changeset Tracking and Administration Summary

For the purpose of managing defects in a branching plan with multiple active release vehicles, it is a useful practice to
Page 17 of 32
update your Bug Work Item templates with an area for tracking merges, e.g. you may have an entry for each active
branch, DEV, MAIN, RELEASE(S) and values of Merged, Merge Required, Merge Not Required. This allows your defect
manager to easily report on the status of defects across active release vehicles. This approach can be easier to manage
than creating a duplicate defect for each branch where the fix is required.
For the purpose of managing changes, particularly in complex branching scenarios, we recommend automating the
3
diagnosis / reporting on merge debt. This can be accomplished in various ways. A simple way is to use tf.exe to run
across all active merge paths to report the state of affairs. The sample below provides an MSBuild based solution to
this. A merge preview is run over a collection of merge paths.
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">


<ItemGroup>
<MergePath Include="DevToReleaseA">
<SourceBranch>$/ProjectName/Development</SourceBranch>
<TargetBranch>$/ProjectName/Releases/RelA</TargetBranch>
</MergePath>
<MergePath Include="ReleaseBtoDev">
<SourceBranch>$/ProjectName/Releases/RelB</SourceBranch>
<TargetBranch>$/ProjectName/Development</TargetBranch>
</MergePath>
</ItemGroup>

<PropertyGroup>
<WorkspacePath>C:\YourWorkspacePath</WorkspacePath>
<IgnoreConficts>true</IgnoreConficts>
</PropertyGroup>
<Target Name="Report" Inputs="@(MergePath)" Outputs="%(Identity)">
<Message Text='"%(MergePath.SourceBranch)" to "%(MergePath.TargetBranch)"'/>
<Exec Command='tf merge "%(MergePath.SourceBranch)" "%(MergePath.TargetBranch)" /preview /recursive'
WorkingDirectory='$(WorkspacePath)' IgnoreExitCode="$(IgnoreConficts)"/>
</Target>
</Project>
4
Alternatively Team Foundation Server provides a rich API to report (VersionControlServer.GetMergeCandidates )
5
and action (Workspace.Merge ) merge debt. A simple UI could be written to provide staff the ability to monitor and
manage the debt. This software could allow a member of the team to determine how many changes are pending, how
many conflicts, auto merge, create a merge task and assign it to a member of the team if conflicts are found and
perhaps allow the discarding of changesets which are not intended for merging. By keeping the merge paths ‘clean’ you
can be more confident that fixes and new work have been integrated into their peer branches.
Visual Studio 2012 Merging Enhancements

The primary areas of improvement are:
 Minimal conflicts when merging – fewer conflicts require user interaction and thus better auto merging
 A new diff/merge experience – a total revamp in Visual Studio 2012, with the out-the-box merge and
comparison experiences now resembling or exceeding many advanced third party tools
 Baseless merge in the UI – see Baseless merging -> Visual Studio 2012
 Merge on unshelve – standard Team Foundation Server merging available on unshelving
6
These changes are all covered in detail in Brian Harry’s blog post, “Merge enhancements in TFS 11” .
3
http://msdn.microsoft.com/en-us/library/cc31bk2e(v=vs.110)
4
http://msdn.microsoft.com/en-us/library/ff735717
5
http://msdn.microsoft.com/en-us/library/microsoft.teamfoundation.versioncontrol.client.workspace.merge(v=vs.110).aspx
6
http://blogs.msdn.com/b/bharry/archive/2011/08/31/merge-enhancements-in-tfs-11.aspx
Page 18 of 32
Baseless Merging
Normally, developers perform bi-directional merges between branches that share a parent/child relationship. On
occasion, a merge needs to be made between two branches that do not have a merge relationship. These types of
merges are called baseless merges. A baseless merge creates a merge relationship between a source and target that is
not part of a direct parent/child branching relationship.
Baseless merging should be the exception rather than the rule. If it is frequently being used, the overall
branching strategy needs to be addressed.
Note
Pros and Cons of Baseless Merging

A baseless merge can add more complexity to an already complex branching scenario. If there seems to be a need to
do baseless merges regularly, it likely points to a flawed branching strategy. However, there are legitimate reasons for
doing a baseless merge, so it should not be ruled out completely. For example, a hotfix may be needed in production,
but it cannot be moved to a DEV branch through MAIN due to a testing cycle occurring in MAIN.
Prior to Visual Studio 2010 SP1, files that are in a delete status in the source branch are not merged to the target
branch. Another problem is since there is no base version; 3-way merging is not possible in a baseless merge. A 3-way
merge compares both source and target files to the base version allowing a better merge experience such as auto-
merging. Auto-merging is not possible with baseless merges, so any conflict needs to be merged manually.
Merge Scenario
In this scenario shown below, there are three DEV branches from MAIN. Within this structure, if a change needs to be
merged from DEV FT2 to DEV FT1, the normal path would first require a reverse integration merge from DEV FT2 to
MAIN. This will then be followed by a forward integration merge from MAIN to DEV FT1. However, if it is not possible
to merge the code to MAIN, the only way to move it from DEV FT2 to DEV FT1 is through a baseless merge.
Figure 11 – Baseless Merge between DEV FT1 and DEV FT2

Since there is no direct branching relationship between DEV FT2 and DEV FT1, a baseless merge needs to be performed
and thus any merge conflicts must be resolved manually. Once a baseless merge is completed, Team Foundation
Server records a merge history and a branching relationship is established.
Baseless Merging in Visual Studio

In Team Foundation Server 2010, a baseless merge can‘t be done through the UI. A baseless merge requires using the
Page 19 of 32
tf merge command using the following syntax:
tf merge /baseless <<source path>> <<target path>> /recursive
For example, the following will do a baseless merge of changeset 150 from DEV FT2 to DEV FT1.
tf merge /baseless /v:C150~C150 “$/TeamProjectA/DEV FT2” “$/TeamProjectA/DEV FT1” /recursive
The following command will do a baseless merge of all changesets up to 150 from DEV FT2 to DEV FT1.
tf merge /baseless /v:C150 “$/TeamProjectA/DEV FT2” “$/TeamProjectA/DEV FT1” /recursive
Subsequent merging can then occur in the UI as the branch relationship will be defined.
In Visual Studio 2012, baseless merging can also be
performed through the UI. If you initiate a merge from
Source Control Explorer, there is a browse button in the
merge window to find branches to merge to
When a selected target branch is not part of a direct

branching relationship, a warning icon will appear next to
the Target branch label with a message indicating a
baseless merge will happen as indicated to the right.
Figure 12 – Baseless Merge Warning
If a baseless merge is performed with “All changes up to a specific version” selected, when checking in a baseless merge
every file will have a merge status next to it since a baseless merge creates a branching relationship for every file in the
parent folder (DEV FT1). If “Selected changesets” is selected, the Pending Changes window will only show the files
included in the changeset and branching relationship will not be established between DEV FT2 and DEV FT1. This is
because the branching relationship will only be established between the files that are included in the changeset.
Figure 13 shows the branching relationship between DEV FT2 and DEV FT1 after a baseless merge has been performed
using the “All changes up to a specific version” option in the Merge wizard.
Figure 13 – Tracking Shows Baseless Merge
Page 20 of 32
Frequently Asked Questions (FAQ) and Answers

What are the disadvantages of cherry picking changes?
Cherry picking is the process of selectively choosing which files/changesets to branch/merge. Although it gives you
total control of when and how you want to execute a merge operation, it can become confusing. Imagine, for example
that you are merging a feature branch into your main source. You then decide that since you know which files have
been changed from that branch you will select only those files to be merged back to main. Unfortunately another
developer had to change more files than you are aware of and because you didn’t execute a full merge you left those
files behind. Now your main source is “broken”, might not even build correctly and you will probably spend hours
trying to discover what went wrong. This is one of the examples of what can go wrong with this practice.
Also, cherry picked changeset can fall in the middle of a future merge range resulting in remerge of that changeset.
This can result in merge conflicts.
While merging all the content of a branch might sound like too much work in some cases, it actually ensures that the
complete solution fits into the model, no files or changes are left behind and no one in your team needs to know which
file was specifically changed in each situation.
Although, there are situations where cherry picking could be necessary, such as when we need to fast-track a critical fix
from one branch into another. But as the complexity of a project increases, cherry picking is more likely to cause
problems such as fixed bugs that appear again in new builds or broken builds due to incorrect file versions.
Are work items a part of the branching/merging model?

No, work items exist at a logical level that is distinct from that of the source control repository. That means the
branching of the source code or merging between two branches has no impact on work items:
 Work items will NOT be duplicated during branching or merging process
 The work item links will NOT be updated or extend with links referencing the new branch/merged items
All branching/merging operations require a new check-in and do not carry over work item history. Although work item
history is not propagated during this operation, previous work item associations are unaffected. Note that since
branch/merge operations require check-in, this provides an opportunity for work item association. Work items may be
associated with the branch/merge changeset; work item association can be forced through check-in policy. For
reverse/forward integration, you may create separate work item associated with a merge. For example, when
integrating code from the development branch into the main branch after finishing integration testing, create the work
item “Complete integration testing for release X.” If it is still necessary to duplicate work items for the association with
the branch/merge operation, use “Copy Work Item” function (see reference). You can copy work items within the same
Team Project or into another Team Project. Note that after copying a work item, the links within copied work item still
reference same artifacts as in the original work item.
Keep in mind that work items in Team Foundation Server 2012 can be organized in a hierarchical manner, therefore you
could possibly have a main work item called “Feature set XYZ” that groups other work items, each with a link to specific
changesets.
Additional Resources
7
 Copy a Work Item
7
http://msdn.microsoft.com/en-us/library/ms181321(VS.110).aspx
Page 21 of 32
What is required to consolidate or transition branches?
Ideally, your branching strategy is the result of planning and reflects the needs and goals of your teams. However, in
today’s constantly shifting environment of mergers and acquisitions, you may find that you will need to integrate the
work of two or more previously autonomous teams into a single consolidated environment. It is important to consider
the benefits vs. cost of making this decision, in terms of several factors including: current configuration, team structure,
release cycles, migration effort required and future needs.
Consolidating and transitioning of branches should be considered with the equivalent importance of the initial
migration of existing source code into the Team Foundation Server environment. Questions that should be asked of the
teams considering this action should include:
1. What are the predominant reasons for considering this action?
2. What are the benefits of this action? What are the benefits for remaining with the status quo?
3. What are the risks of consolidation?
4. What resources will be required to complete a consolidation?
5. What is the exit plan?
6. What effects will this have on future development?
7. How will any existing best practices be incorporated?
8. Do we need to keep history and associated work items with the source?
Once you have decided on the answers to these questions, your next steps will be determined by whether you wish to
consolidate your branches or transition into a new environment. Transitioning to a new branch may be the easier of the
two options. You can essentially lock off your existing branches and have everyone work in the new environment from
the designated start point. This is most appropriate when applications that have been created and maintained by teams
that were previously separate and do not have anything in common, other than they are now all products of a
combined entity.
For consolidating branches, you will have to review your existing branches and determine what must be included. Once
you have made those decisions, you will need to create a new mainline and proceed to migrate each designated
branch. Along each step, you should verify that branch that is migrated does not break the new mainline. If at all
possible, this should be done in a sandbox environment prior to attempting in a production environment.
It should be expected in either case that you may find some unexpected results when attempting consolidation or
transitions, both at the time of and later.
8
 Branch Folders and Files
9
 Merge Folders and Files
Is there a preferred "Branch from version" value when creating a branch?

When creating a branch, there are five options available to choose the source from. They are: changeset, date, label,
latest version and workspace version. Each of these options addresses a very particular need.
It is important to call out that Team Foundation Server uses labels to refer not to a point in time but rather to any
collection of files that have been grouped together by the user, so a branch that is created by label is often specific to
the needs of an individual developer or task. The same thing applies when creating a branch from a workspace version.
In Team Foundation Server, workspaces are mapped from the developer’s machines back to the server, so a branch
would reflect the local files. Labels in Team Foundation Server are changeable. Deletions are also not part of the label.
8
9
Page 22 of 32
When creating a branch that will address the needs of the larger team, using date, latest version or changeset would be
more preferable. Each one serves a different function. For example, if you were in a hotfix situation, creating a branch
from the most relevant stable version would be most applicable. If you were fixing a bug or in maintenance mode and
you knew where the break occurred, you would branch by changeset. If you are moving into the next iteration of your
release, branching by date might be the best fit.
Additional References
10
How do I manage permissions across branches for my team?

Managing access and permissions to source control should be carefully evaluated. Taking the time to evaluate the
levels of access that are needed across roles and defining a roles and responsibilities matrix can provide you with a
consistent and security focused solution. Consider using secure groups, based on Active Directory, since Team
Foundation Server can refresh automatically. Remember to include those people from outside your immediate teams
who might also need access, such as IT Ops or Support. You may also need to take into consideration any corporate
security or governance policies that apply.
In terms of source control, permissions in Team Foundation Server 2012 can be granted separately from permissions to
team projects, work items, portals and reporting services. A user may have distinct permissions on each branch to
which they have access. Permissions may be inherited or granted explicitly. For each branch that you wish to set
permissions to, take the following steps as referenced in the MSDN article “How to: Control Access to Team Foundation
Version Control”.
Branch permissions will have the same permissions as the main branch it was created from. It is important to set the
permissions to a more restrictive level immediately after the branch is created.
It is a good practice to set permissions to the level of access actually needed rather than using a more generalized
model. Ideally, branch permissions should be restricted to your team members that actually require access to source
controlled items. The permissions should be specific to the branch rather than inherited. Implementing this practice will
make your branches more secure against changes that were not meant for your branch. Otherwise it can easily happen
that a developer checks in changes to the wrong branch by accident. One scenario would be to grant all external
developers access to a development branch but not to your main branch. The specified permissions on your main
branch control who is allowed to merge the changesets from the development branch to the main branch.
Similar to Team Foundation Server 2010: The Manage branch permission is required to be able to convert folders to
branches and vice versa. Additionally it allows editing of branch properties as well re-parenting the branch. Users with
the Merge permission for a given branch can merge changes into that branch.
11
 Control Access to Team Foundation Version Control
How should bugs be handled over branches?

Branching of source code has no impact on work items (e.g. bugs). It means that the bugs are not cloned during the
branching process. So, the handling of the bugs depends on the overall process:
Case 1: Responsibility and ownership for the bugs should also move to the team being responsible for the new branch
(either within the same team project or in another team project).
The bugs can be copied into a new or within the same team project and additionally assigned to different areas, which
might correspond to branches. The fields in the newly created work item are pre-populated with the value of the
10
11
Page 23 of 32
corresponding fields in the source work item. The work item links will also be copied. Be aware of the following
limitations:
 A work item belongs to the team project in which it was created and cannot be moved (only duplicated) to
another team project
 Field information can only be transferred, if the target work item type has the same fields defined
 Permissions on both team projects are required
When copying into another team project, the original bug should be closed and linked with the copied bug.
Case 2: Only source code will be branched (within the same team project or into another team project). Responsibility and
ownership for the bugs will stay in the original team.
The bug fix can be implemented in the original source code or in the branch source code. When fixing the bug in the
branch source code, the bug needs to be updated as resolved within the merge process.
Case 3: Only source code will be branched into another team project. The responsibility for testing the bug fix is located in
both projects (e.g. if the bug fix must also be retested in the new branch)
In this case the bugs can be duplicated into the new team project by copying the relevant bugs. So, both teams can
track the quality verification of the bug fixes without dependencies.
12
 Copy a Work Item
13
 Create or Delete Relationships Between Work Items
What are labels and when should they be used?

In Team Foundation Version Control, a label is a marker that you can attach selectively to a set of otherwise unrelated
file and folder versions in the source control server to facilitate their collective retrieval to a workspace for either
development or build purposes. Typical scenarios to use labels can be to represent a snapshot of source code that was
successfully built on a given day (Team Build does this automatically for each build) or store a version of some changes
made to the code base.
Depending on the permissions granted to specific users, labels can be modified – files can be changed, added,
removed from the label. While powerful in its own respect, labels need to be used with caution given that:
 Team Foundation Server does not retain history of changes made to the label.
 Given certain permissions, labels might be deleted or otherwise invalidated by changes, and there is no
way of auditing those changes.
 There can be contention for a label name as label names must be unique throughout a specified scope
 Items deleted will not be available in a label.
Labels are recommended in cases where a snapshot of sources is needed for any future references/use. In scenarios
where it can be guaranteed via permissions that the label will not be changed, we can use labels as markers for
branching i.e. if you do not have an immediate requirement to branch but expect a need for branch in future, you can
Label the source now and then branch from the label when required.
For any other development activity that needs to use a snapshot of sources over a longer duration of time, combined
with the need for history and auditing of changes, and especially where several users might need to access the
snapshot and possibly change the files and their contents, it is recommend to use branching. Branching by definition
12
13
http://msdn.microsoft.com/en-us/library/dd286694(v=vs.110).aspx
Page 24 of 32
allows files and folders to diverge from their original state (while also preserving the original state), include history, and
allow a rich set of file- and folder-level permissions to control changes.
Can source code be branched across team projects?

Source code can be shared between Team Projects in various ways within the same TPC, including branching source
from one Team Project into another. One of the common scenarios where a source code is branched between Team
Projects is when we have a separate Team Project, which houses codebase of common functionalities and is referenced
by multiple projects. A separate team project for common assemblies also provides a convenient place to manage
artifacts associated with that shared source such as design documents and bugs. The downside of branching across
team projects is that new sources can be brought to the branch only by merging it from the parent project.
When creating a new Team Project, when should one use “Create a new source control branch
option”?
When creating a new Team Project, “Specify Source Control Settings” tab has the following options: “Create an empty
source control folder” or “Create a new source control branch”.
With the “Create a new source control branch” option selected, new Team Project source control folder will contain all
data contained in source control folder of another existing Team Project. Essentially, by enabling this option you
declare that “Team Project X will contain all of the sources in Team Project Y”.
Thus the answer to the question whether to use this option depends on the internal structure and contents of the
existing Team Project. If the branch is created from existing Team Project that contains code related only to single
release, and new Team Project being created will be next release based solely on the previous code base, using “Create
a new source control branch” may be a valid option.
However, if existing Team Project contains several releases (even if they are internal ones) the better option would be
to “Create an empty source control folder” in a new Team Project, and then branch off specific folder in the existing
Team Project rather than from the root. That would allow bringing over only desired folders, and generally provide for
far better flexibility in creating desired folder structure in the a new Team Project.
Below diagrams illustrate the problem:
Figure 14 – Create a New Source Control Branch
Page 25 of 32
Figure 15 – Create a New Source Control Branch – Alternative
What is baseless merge and how does it compare to regular merge?

A baseless merge allows merging two folders that do not already have merge relationship. Normally a merge
relationship is created when a new branch is created. The parent branch and child branch have a merge relationship.
Two different child branches, although they share the same parent (sibling branches) do not have a merge relationship
directly with each other.
Once baseless merge is performed it becomes possible to perform ordinary merges between the branches (as if the
two branches had a normal merge relationship between them).
Though baseless merge is helpful when merging between two logically related folders is absolutely necessary in the
absence of main-branch relationship, it shouldn’t be seen as a normal process but rather as an exception. After all, if
the branching model is effectively planned and implemented, a baseless merge shouldn’t be necessary.
As an administrator of Team Foundation Server 2012, you should understand that baseless merges are likely to be an
indication that the branching structure implemented or the process around it is not serving the purpose of simplifying
and standardizing the branching/merging model of your source code repository. Moreover, frequent baseless merges
also mean that too much manual intervention is currently necessary in order to deliver branching/merging to your
source code. This manual intervention can eventually lead to human error and consequently inconsistent source code
state. A similar risk as the one mentioned earlier in this section about cherry picking.
Can branches be deleted?

Deleting branch is not different from deleting any source control folder. One difference to be aware of when deleting
branch is the effect it may have on future merge operations.
Team Foundation Server is capable either to merge (FI) a parent branch to a direct child branch or to merge (RI) a child
branch back to its immediate parent (unless you perform baseless merge or re-parent branch after a baseless merge);
thus if intermediate branch is deleted, certain merge paths will be invalidated.
Consider the following example:
1. Create branch A to B
2. Create branch B to C
Merge from A to C is possible (from A to B, from B to C) as is merge from C to A (C to B, B to A). However, if B is

deleted, those merges become impossible.
Therefore, if you were to delete a branch, consider if it has any child branches created off it. If such branches exist,
consider making the branch invisible through the use of source control permissions; that would allow future merges
while hiding the folder from the end user.
Page 26 of 32
14
 Branch Re-parenting at
15
 Team Foundation Server Permissions
When merging two branches with “All changes up to a specific version” …

When merging between two branches with “All changes up to a specific version” option selected, what version type is
preferred to specify the version (“Latest Version” [default], “Changeset”, “Date”, “Label” or “Workspace” version)?
Depending on the option selected, different changesets will be merged as described below:
 When “Latest Version” option is selected, all unmerged changesets from source branch checked in prior to
the moment of merge will be merged to the target branch. However, since there may be active
development ongoing on the source branch, the exact changes being merged may not be well-defined.
 When “Changeset” option is selected, all changesets from the source branch checked in up to the specified
changeset will be merged to the target branch (specifying changeset is equivalent to specifying date,
where date is the date of the changeset check-in).
 When “Date” option is selected, all changesets from the source branch checked in up to the specified date
will be merged to the target branch.
 When “Label” option is selected, all changesets labeled in the source branch will be merged to the target
branch. Because labels in Team Foundation Server do not include “delete” changes, delete changes will
never be merged over to the target branch.
 When “Workspace” option is selected, all source branch changes up to the versions in the specified
workspace will be merged to the target branch. In a manner similar to “Label” option, changes of type
“delete” will not be merged.
Thus, as the result of limitations of “Label” and “Workspace” options, those are not recommended for performing
merges unless no delete changes are ever performed. “Latest Version” option may be used when one is reasonably sure
what the latest version contents are. The temporary “freeze” on the source branch may be achieved by applying the
lock prior to the merge. Using “Changeset” or “Date” options provide well-defined checkpoint of what merge contents
are and should be used where possible.
If you are unsure about which changesets you did not merge yet, then you might want to select the “Selected
changesets” option, which will give you a list of the pending changesets that have never been merged.
16
 Deceptive Allure Of Merging With Labels
What is the “Re-parent Branch” function and when should it be used?

Re-parent Branch is a feature that can be used to establish a parent-child relationship between baseless merged
branches as well as to alter existing branches' parent-child relationship in a branch hierarchy.
However, 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.
14
http://blogs.msdn.com/b/hakane/archive/2009/05/19/enable-branch-visualization-in-upgraded-team-projects-tfs-2010-beta1.aspx
15
16
http://blogs.msdn.com/Team Foundation Servervcs/archive/2007/03/22/the-deceptive-allure-of-merging-with-labels.aspx
Page 27 of 32
17
 Branch Re-parenting
What is the difference between folders and branches?

Starting with Team Foundation Server 2010 there is a distinction between branches and folders in version control.
Assuming the necessary permissions a user can convert folders to branches (and vice versa).
This new concept of having a branch as a first-class object enables some branch-specific features as well as the ability
to store properties like the owner and a comment to each branch, making branch management easier for teams with a
large number of branches.
After converting a folder to a branch you can use many of the new features related to branches like visualizing the
branch hierarchy or visually tracking changesets in order to see what branches contain the changeset, and when
changesets were merged into specific branches.
When you upgrade from Team Foundation Server 2008 to Team Foundation Server 2010 or Team Foundation Server
2012 you should convert branch folders to branches.
Not all folders in Team Foundation Server 2008 are branches. Some folders are containers, and will
continue as folders in Team Foundation Server 2012.
Note
On the security side, there are two new permissions: The Manage branch permission is required to be able to convert
folders to branches and vice versa. Additionally Manage branch permission allows editing of branch properties,
creating new branches from a branch, and re-parenting a branch. Users with the Merge permission for a given branch
can merge changes into this branch.
To summarize, when you want to create a new child branch from a parent branch you need Manage branch
permissions on the source branch (the parent branch). When you want to merge changes into a branch, you need
Merge permission on the target branch.
18
19
 View the Branch Hierarchy of a Team Project
20
 View Where and When Changesets Have Been Merged
21
 Team Foundation Server Permissions
How to handle Branch, File and Folder rename?

Starting with Team Foundation Server 2010, version control operations are switched from Item mode to Slot mode.
This switch over has improved the robustness of merge and the performance of the system. But, it will create few
problems in case of branch rename operations because in slot mode operation branch rename is actually a branch and
delete process in background. This means new name is branched from the old, and then old name is deleted. It would
show the pending change as “source rename” to identify the rename operations.
Below are some of the issues with Branch renaming operation which can lead to confusion.
 The next merge from the renamed branch to related branches might generate more than necessary conflicts.
17
http://blogs.msdn.com/b/hakane/archive/2009/05/19/enable-branch-visualization-in-upgraded-team-projects-tfs-2010-beta1.aspx
18
19
http://msdn.microsoft.com/en-us/library/dd465202(VS.110).aspx
20
http://msdn.microsoft.com/en-us/library/dd405662(VS.110).aspx
21
Page 28 of 32
 If new branch is created with old deleted name from another parent branch. Then, the new created branch will
also show the old one’s parent branch as a target branch in merge wizard. Also, in this scenario the new branch
will contain all the history of old branch as well.
 Branch rename can also cause problems in Branching hierarchy view when tracking changeset.
Branch rename should be avoided in first place and as an alternative you should create a new branch instead of
renaming old one. In this approach, it’s important to choose the correct moment to create the new Branches, so that
you can merge all changes to a parent branch and then re-branch to create a new branch hierarchy.
If you want to go with Branch rename operation then you need follow below steps:
 Get all team members to check in their local changes in old branch.
 Merge pending change sets from branch which you want to rename to all its related branches.
 Rename the branch and check-in the changes
 Merge again rename changes from new branch to all related branches
Folder and File rename is also branch and rename operation. After a folder or file is renamed, the new item will not
show all related branches in target option in merge wizard because new item is considered out of scope of the merge.
To perform merge at folder or file level after rename operation, first you need to merge the changes at parent or
branch level to all related branches.
22
 Changing to Slot Mode in TFS2010 version control
23
 Renaming branches in TFS2010
Why should we use integration between our main and feature branches?
Well that question sounds much more difficult than it actually is.
If we start by looking at why we use integration in our branches in general we can see that whenever we have
something that origins from several sources that we want to put together and most important make sure it works
together before propagating the changes, we will use some kind of integration technique.
The workspace way of integrating

Consider the picture below, the two children at the top level could be representing local workspaces belonging to
members of the team working in parallel against a feature branch which here is represented by the parent at the
bottom.
Picture 1 Parent branch with two children

If we assume that the children in previous picture are local workspaces belonging to two team members then we are
not so surprised when we start talking about getting the latest version. In fact we are doing that all the time to make
22
http://blogs.msdn.com/b/mitrik/archive/2009/05/28/changing-to-slot-mode-in-tfs-2010-version-control.aspx
23
http://blogs.msdn.com/b/chandrur/archive/2010/06/09/renaming-branches-in-tfs-2010.aspx
Page 29 of 32
sure that we have our local workspace updated with the latest changes that the other team members have added
recently.
Picture 2 Getting latest version from parent to child A

This is more or less default behavior, we say “let’s get the latest version and see if my changes are working with that
before I do a check in of my changes”. By using this way of working I always make sure that any merge conflict that
could exist together with any functional discrepancies will be taken care of before I do my check in.
Picture 3 Returning new update from child A to the parent

Once this check in is made, the other team members will use the same method and do a get latest to make sure they
always have the latest code version to test their changes against.
Picture 4 Getting latest version from parent to child B

Once they have checked that everything is working correctly and no merge conflict exists, they could do their check in.
Picture 5 Returning new update from child B to the parent

And then it continues, getting latest and checking in, on and on repeatedly until we are done with our work in our
branch. What we have done is actually what we call integration. We have integrated our work together making sure
that what we add to our branch is always correct. Whenever we are doing a get latest we are talking about Forward
Integration (FI) and whenever we check in our update to our parent we are talking about Reverse Integration.
The branch way of integrating

So how does all this affect my decision if I should use integration between the feature branches and the main branch?
Well if we always have the need of a stable functional main branch then it wouldn’t be recommendable to integrate the
changes from several feature branches directly into our main branch. That way we jeopardize the functionality in our
Page 30 of 32
main branch and we could introduce code from two features that don’t work correctly together. Hence we need some
kind of collector where we could perform our integration and test it before deciding to move everything into our main
branch.
Picture 6 Using an integration branch between feature branches and main branch
In the picture above we can see how it looks. We have the integration branch (in the middle) that is a child of our main
branch (at the bottom) and we have our feature branches (at the top) as children to the integration branch.
Updating the feature branches

By using Forward Integrate we update our feature branches with latest changes in the integration branch. After taking
care of any merge issues and making a final test that our changes is working correctly in our feature branch we use
Reverse Integration to move our changes back down into the integration branch. The members working on the other
feature branches are also using the same approach. We are simply talking about using FI-RI integration between our
feature branches and the integration branch.
Updating the main branch

Once we decide that what we have collected in our integration branch is working correctly by performing tests on the
content we could make a decision if the changes are complete and do a Reverse Integrate into our main branch.
Ownership
Because we are mixing content from several branches together it could be a good advice to establish some kind of
ownership of the both parents to make sure the reverse integration will occur at proper occasions. Reverse Integration
to the integration branch could affect ongoing tests on that branch and shouldn’t be performed without control. The
same goes for Reverse Integration down to the main branch, since this is the releasable code it means that adding new
features without control could affect an upcoming release. There are several workarounds for this like using the content
of main based on labels or changesets but the more well-defined ownership we have over the different branches the
easier our work will become.
Conclusion
By using the integration branch between our main branch and our feature branches we simply gain confidence that we
only add newly tested and feature complete functionality back to our main branch. We do this iteratively and hence the
main branch will always be stable and releasable with increased functionality over time.
So the conclusion is that we always need a collector in the form of an integration branch before our main branch if we
have more than one branch that is feeding with new functionality.
Is the integration line pattern useful in other cases?

Yes, integration branches could always be used whenever we have the need of bringing several branches together into
one before Reverse Integrate it further down to the parent. That way we never risk adding code to the parent without
having the opportunity to test everything together before Reverse Integrating it.
Page 31 of 32
Appendix
Additional Resources & References
24
Professional Team Foundation Server 2012 (Wrox)
25
This guide including public discussions - Visual Studio Team Foundation Server Branching Guide
Other ALM Rangers Resources

Understanding the ALM Rangers – http://aka.ms/vsarunderstand
Visual Studio ALM Rangers Home Page – http://aka.ms/vsarmsdn
Visual Studio ALM Ranger Solutions – http://aka.ms/vsarsolutions
Figures Reference
Figure 1 – Basic Branch Plan ..................................................................................................................................................................................... 11
Figure 2 – Standard Branch Plan ............................................................................................................................................................................. 12
Figure 3 – Advanced Branch Plan ........................................................................................................................................................................... 13
Figure 4 – Code Promotion Plan ............................................................................................................................................................................. 14
Figure 5 – Branch by Feature Plan .......................................................................................................................................................................... 15
Figure 6 – Horizontal Timeline ................................................................................................................................................................................. 16
Figure 7 – Vertical Hierarchy..................................................................................................................................................................................... 16
Figure 8 – Swimlanes ................................................................................................................................................................................................... 16
Figure 9 – Tracking basic merge debt .................................................................................................................................................................. 17
Figure 10 – Tracking basic merge debt ................................................................................................................................................................ 17
Figure 11 – Baseless Merge between DEV FT1 and DEV FT2 ...................................................................................................................... 19
Figure 12 – Baseless Merge Warning .................................................................................................................................................................... 20
Figure 13 – Tracking Shows Baseless Merge...................................................................................................................................................... 20
Figure 14 – Create a New Source Control Branch ............................................................................................................................................ 25
Figure 15 – Create a New Source Control Branch – Alternative ................................................................................................................. 26
Tables Reference
Table 1 – Branching Vocabulary ................................................................................................................................................................................ 5
Table 2 – Branch Type Considerations ................................................................................................................................................................... 9
Table 3 – Basic Branch Plan Summary .................................................................................................................................................................. 11
Table 4 – Standard Branch Plan Summary .......................................................................................................................................................... 12
Table 5 – Advanced Plan Summary ....................................................................................................................................................................... 13
Table 6 – Code Promotion Branch Plan Summary ........................................................................................................................................... 14
Table 7 – Branch by Feature Plan Summary ....................................................................................................................................................... 15
Table 8 – Branch Visualization Summary ............................................................................................................................................................. 16
Table 9 – Changeset Tracking and Administration Summary ..................................................................................................................... 17
24
http://www.amazon.com/Professional-Team-Foundation-Server-2012/dp/1118314093/ref=la_B0045P5RCW_1_2?ie=UTF8&qid=1346789604&sr=1-2
25
http://vsarbranchingguide.CodePlex.com
Page 32 of 32

Guia Basica de Braching

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Guia Basica de Braching

Enviado por

Direitos autorais:

Formatos disponíveis

2012

Visual Studio ALM Rangers

Development Branch Changes for next version work

Branching with Labels

Figure 1 – Basic Branch Plan

Usage Scenarios Considerations

Figure 2 – Standard Branch Plan

Usage Scenarios Considerations

Figure 3 – Advanced Branch Plan

Figure 4 – Code Promotion Plan

Figure 5 – Branch by Feature Plan

Figure 6 – Horizontal Timeline

Table 8 – Branch Visualization Summary

If you have a basic branch plan like the one

Figure 9 – Tracking basic merge debt

In the advanced branch shown to the left,

Figure 10 – Tracking basic merge debt

Table 9 – Changeset Tracking and Administration Summary

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

Visual Studio 2012 Merging Enhancements

Pros and Cons of Baseless Merging

Figure 11 – Baseless Merge between DEV FT1 and DEV FT2

Baseless Merging in Visual Studio

When a selected target branch is not part of a direct

Figure 12 – Baseless Merge Warning

Figure 13 – Tracking Shows Baseless Merge

Frequently Asked Questions (FAQ) and Answers

Are work items a part of the branching/merging model?

Is there a preferred "Branch from version" value when creating a branch?

How do I manage permissions across branches for my team?

How should bugs be handled over branches?

What are labels and when should they be used?

Can source code be branched across team projects?

Figure 14 – Create a New Source Control Branch

Figure 15 – Create a New Source Control Branch – Alternative

What is baseless merge and how does it compare to regular merge?

Can branches be deleted?

Merge from A to C is possible (from A to B, from B to C) as is merge from C to A (C to B, B to A). However, if B is

When merging two branches with “All changes up to a specific version” …

What is the “Re-parent Branch” function and when should it be used?

What is the difference between folders and branches?

How to handle Branch, File and Folder rename?

The workspace way of integrating

Picture 1 Parent branch with two children

Picture 2 Getting latest version from parent to child A

Picture 3 Returning new update from child A to the parent

Picture 4 Getting latest version from parent to child B

Picture 5 Returning new update from child B to the parent

The branch way of integrating

Updating the feature branches

Updating the main branch

Is the integration line pattern useful in other cases?

Other ALM Rangers Resources

Você também pode gostar