Branching and Merging Guide … are we on track with our strategies?

Updated: 2013-09-06

The Branching and Merging Guide team has embarked on an adventure to upgrade the guidance to embrace Team Foundation Server 2013, TFVC, NuGet and Git. The plan is to ship four focused eBook styled guides, walkthroughs, hands-on labs and an upgrade of the TFS Branch Tool.


In this post we would like to take the opportunity to ask you a few questions to ensure that Part 1 – Branching Strategies will meet your expectations.


In the Branching Guide v2 we talk about the main-only, Basic (single branch), Basic (dual branch), Standard, Advanced and Feature branching strategies. As part of the Version Control Guide we are re-visiting the v2 content and deciding what is missing, what is redundant and what can be improved.


  1. Are we missing an important strategy?
  2. Are the strategy names meaningful and descriptive?
  3. What are your thoughts on the following strategy names to replace the current None, Main, Basic, Feature, Standard and Advanced names?
    • No Branching
    • Single Mainline
    • Development Isolation
    • Feature Isolation
    • Servicing Isolation
    • Release and Servicing Isolation
  4. Would a walkthrough and checklist of starting with no branching strategy and moving through main-only, basic, standard, advanced and beyond add value?
  5. What can we improve on in terms of “Branching” section in the v2.1 branching and merging guide?

Please share your candid thoughts by adding a comment below or pinging us here.

Comments (12)

  1. Matt Ring says:

    What about a branching strategy that only ever has one version in production at a time (for example, web site development)?  Most of the branching strategies have different, parallel release branches (v1, v2, etc.) This seems to work well if you need to maintain multiple release versions of a product, but what if you only ever have one release version in production at a given time?  The Feature branch strategy is the only one that appears to address that scenario (at least, in the above screenshots).

    What about a Code Promotion branch strategy (as is described in the Professional TFS 2012 book)?



  2. Ralph Jansen says:

    Is there a way to make those strategy drawings easily? I like the layout. It is clear. I always draw them myself but digital is better.

  3. I like the four guides.  Should the fourth one be named "Git for TFVC Users"?  That's how I usually see TFS' original version control referenced.


  4. Frerdrik Normén says:

    Branch by Abstraction and using feature toggling etc would be nice. Maybe that is included in the one main branch strategy?

  5. Mike Fourie says:

    Once all 4 are done I'd like to have a single ebook instead of 4.


  6. B. Ward says:

    Could you increase the image resolution?  It's very difficult to read as is.

  7. @B. Ward … intention was not for readers to drill into the images, but for the "thumbnails" to refresh their minds on the guidance and high-resolution images you can find at I will add a link to the downloads, so that users will automatically divert to the guide when they click on the thumbnails.

  8. Giulio Vian says:

    I think we should refer to the seminal PLoP98 paper "Streamed Lines: Branching Patterns for Parallel Software Development"

  9. Allen Feinberg says:

    I like new names:

    ◦No Branching

    ◦Single Mainline

    ◦Development Isolation

    ◦Feature Isolation

    ◦Servicing Isolation

    ◦Release and Servicing Isolation

    But I don't see a branching strategy covering the feature crews model that Microsoft uses throughout MSN and Office. It's the multiple team approach that we've been following for the last 2+ years that's made TFS usuable,

    Checklists would be helpful, especially around baseless merging, labels, and cross team project branching.

    If I could ask for one thing in the new release it would be to provide more examples on how to handle complex merging scenarios.

  10. @Allen, our projects are also based on a multiple team approach (…/665655), whereby some are predominantly using no branching, single mainline and feature isolation. Do you see a strong correlation with multiple team approach and branching? If yes, could you elaborate so that we can take it into consideration in the new guide?

  11. @Allen, we are also planning to include a walkthrough starting with nothing and ending up with release and servicing isolation, as well as a walkthrough of unexpected blips in a standardised branching model, where a team needs to change its process to react to a short-term event. Hope that will address your last ask above.

Skip to main content