Team Development with Visual Studio Team Foundation Server

never need a branch. Development teams working on longer release cycles (e.g.,
packaged Independent Software Vendor [ISV] applications) are more likely to employ
branching as part of the development process.
Additional Resources
• For an introduction to branching and merging, see “Branching and Merging Primer”
at http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx
• For more information about branching, see “How to: Branch Files and Folders” at
http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx
• For more information about merging, see “How to: Merge Files and Folders” at
http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx
• For additional descriptions of how to branch and merge in Visual Studio 2005, see
“Branching and Merging Team Foundation Source Control” at
http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
How to Use Branching to Support a Release
Use a Release branch when you are ready to stabilize your build prior to release.
The following is an example of what your branch structure might look like after you have
created a Release branch:
• Main – Integration Branch
o Source
o Other Asset Folders
• Releases – Container for release branches
o Release 1 – Release branch
• Source
Keep the following recommendations in mind when working with Release branch:
• When to branch – When you are ready to release, integrate everything into the
Main branch and then create Release branch that can be used to stabilize the
application prior to release.
• When not to branch – If you are using one TFS project per release, you can use
the new project to continue development, instead of a branch in the current
project.
• Permissions on branch:
• Prior to release – assign read/write permissions to all developers.
• After release – Assign read/write permissions to developers working on
hotfixes, read-only for everyone else.
• Build frequency in branch – The builds are performed on-demand.
• Testing focus in branch – Sign off on release.
You should use the Release branch for the targeted fixes and changes necessary in order
to stabilize a build prior to release. Development of the next version of your application
can occur in parallel in your Development or Main (integration) branches so that they can