Team Development with Visual Studio Team Foundation Server

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 do I use branching to reduce conflicts between features?
Use Feature branches to improve the integration and stabilization of breaking changes
across features.
The following is an example of what your branch structure might look like after you have
created Feature branches:
• Development – Container for Feature branches
o Feature A – Feature branch
• Source
o Feature B – Feature branch
• Source
o Feature C – Feature branch
• Source
• Main – Integration branch
o Source
o Other asset folders
Keep the following recommendations in mind when working with Release branches:
• When to branch: Feature teams often have source file overlap, thereby
increasing the potential for build breaks and check-in conflicts. If you are
experiencing these types of problems, consider feature branches for each feature
to provide feature isolation. You can create these off a Main branch for small
teams, or off Team branches for larger teams.
• When not to branch: If you are only creating CI builds, or your daily builds are
already predictably stable, you might not need the extra overhead of feature
branches.
• Permissions on branch:
o Read/write permissions for developers on the Feature branch.
o Read-only for everyone else.
• Build frequency on branch: CI builds.
• Testing focus on branch: Feature and quick feedback testing.