![](https://csdnimg.cn/release/download_crawler_static/6848577/bg6.jpg)
ALM Rangers - Visual Studio Branching and Merging Guide
Page 6 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