This project has moved and is read-only. For the latest updates, please go here.

Branch-by-Release vs Basic plan?

Feb 21, 2011 at 4:56 PM

I'm curious about the relative benefits of Branch-by-Release (as described here

and the Standard plan.


Standard plan:   Dev --> Main --> SP --> Release

Branch-by-Release 2:     Main --> Release1,    Main --> Release2

Bugs are fixed on the release branches and merged back to main.


Branch-by-release is more "branch-on-demand", while the Basic and Standard plans set up a bunch of branches at the outset.

Is there a benefit to having these branches ready to go? Is the cost of forking off a new branch so high?

The Branch-by-Release seems to be simpler (fewer branches active at any one time) than the Standard plan.

Feb 23, 2011 at 2:15 AM

There are several important distinctions. Most importantly is where development (check-ins) takes place. In the Rangers Branching Guidance, development occurs in a Development branch (or set of branches). These are children of the Main branch. Conversely the article you reference suggests that "Most development happens on the Main line of code". The problem with the approach outlined in this article is there is no stable main branch. If development happens on the main line (main branch), it is likely to be quite unstable. In the Rangers branching guidance the Main branch is used to stabilize code (QA) before releasing it to your customers.

The Branch by Release pattern described focuses almost exclusively on release branches and offers no development isolation. Development should be isolated from Main, and the Release branch(es) should be isolated from Main as well. If you look at the Basic branching plan in the Rangers Guidance, you will see three branches (Development, Main, and Release). If you need to support more than one release, you can create a second, third, fourth Release branch as needed. In this respect the Basic Branch plan is most similar to the Branch by Release described in the article.

The difference between the Basic Branch plan and the Standard Branch plan is the addition of another level of branching on the release side. This branch, SP, is used for post-release sustained engineering. Once vNext code is stabilized in Main, Main is branched for Release. In the Standard Plan, you would first branch Main -> SP, and immediately thereafter branch SP -> Release. We recommend having two levels of branch on the Release side so that you can *lock or tie down* the Release branch (by making it read-only). Post release bug fixes can be made in the SP branch, and then merged (RI) to Main where they can become part of vNext Development. This allows a flexible approach for having a read-only copy of the code that is released (major releases) for audit or regulatory purposes, while at the same time providing a branch (SP) where sustained engineering fixes or service packs can be made.

It is important to note.. that while code is under development (in the Development branch), I refer to this code as vNext. When code reaches a level of completeness and quality in the Development branch, it is merged (Reverse Integration, or RI) to Main where vNext is stabilized for release. When it is ready for release, it is branched to release (one, two, or three branches are created at the same time - SP, Hotfix, and Release). At this point the code in the Release branch(es) are vCurrent, and the Development branch is opened up for vNext. Main is now available for stabilizing vNext.

A major weakness of much of the whitepapers and blogs dealing with branching, including the article you refererence, is the tendency to treat branching for development as mutually exclusive with branching for release. You often see the Branch for Release pattern and the Branch for Features pattern discussed separately. These whitepapers do not illustrate how these two patterns can work together and do not need to be mutually exclusive. In the Rangers Branching Guidance, we will be adding more examples of how to add complexity on the development side of the branching structure, to go along with the options already in the guidance for adding complexity on the release side (basic, standard, and advanced are essentially only different on the release side).

Look for Branching for Scrum, Branching for Agile, Branching for Parallel Feature Teams, Considerations for how to integrate multiple development (feature) branches, etc. These will all show various types of complexity on the development side of the branch structure and will work well with whatever pattern you choose for the release side of the branch structure.

Finally, a good branching strategy must address branching structure as well as branching and merging process. Look for the next release of the Rangers Branching Guidance to offer more insight in terms of process as well as structure.

One merging process we will describe is how to move a bug or hot fix from a v1.0 Release to a v2.0 Release branch. The article suggests doing a baseless merge. Depending on the timing of releases, a baseless merge to bring a fix from one release to another may be a good solution. On the other hand, if you have not yet released V2.0, then merging the fix (RI) to Main will incorporate the fix into vNext (v2.0) where it can be part of the stabilization of vNext before release.

I disagree with the characterization of Branch by Release as a branch on demand, as distinguished from Basic, Standard, Advanced plans from the guidance. We do not recommend creating a bunch of branches at the outset. Please re-read the guidance. The Main and Development branches are created at the outset, but the Release branch(es) in the Basic, Standard, or Advanced plan are created later, when vNext is ready to release. In this respect the guidance is no differenct from the article.

As for having fewer branches active at any one time, this is not, in my opinion, a primary goal. Certainly we want to minimize branches, because branching brings with it a cost (merging and resolving merge conflicts). In my view the Branch by Release approach discussed in the article does not have enough branches at any point to properly provide two essential forms of isolation provided by the Basic, Standard, and Advanced Plans. These two essential forms of isolation are: Isolating ongoing development from Stabilization (QA testing) prior to release, and Isolating Stabilization of vNext from support for a Release (vCurrent).

I hope this helps.

Bill Heys
VS ALM Ranger



Feb 23, 2011 at 2:21 AM

As a separate point, the article describes "Any changes, such as bug fixes, that are made on a branch or a sub-branch are forward-integrated back into the Main line." Given that the Main branch is the parent to the major Release branch(es), when you integrate changes from a release branch back to Main, this is more accurately described as Reverse Integration, not Forward Integration.

Most people are familiar with Forward and Reverse Integration. Using these terms properly will help eliminate confusion. When merging from Parent to Child (for example from Main to Release 1.0), you are doing a *Forward* Integration. When merging from child to parent (for example from Release 1.0 to Main, or from Release 1.1 to Release 1.0 in the article), you are doing Reverse Integration.

Bill Heys

Feb 23, 2011 at 2:32 AM

I would also disagree with some of the other branching patterns suggested by the author of this article. For example Branching by Quality. In my view, QA testing is done in the stable Main branch. At any time you can deploy code from the Main branch to QA. You do not need a separate branch for QA. In fact having this branch simply doubles the merge effort to move code from a development branch to the Main branch, or vice versa.

This is another example of how some *experts* advise separate patterns for development from patterns for release and never really describe how or why to combine them into a cohesive branching strategy.

Bill Heys

Feb 23, 2011 at 2:46 AM

There is no need for four level of branches described in the Branch by Quality pattern (Production, QA, Bug Fix, and Development). In the Rangers Guidance, the Main branch is where QA builds are deployed from. If a bug is found in QA, we fix the bug in the Development branch, not in a separate Bug Fix branch. Having a separate Bug Fix branch is going to create a merging nightmare. Consider this: Start with a Production branch (more on this later). From Production, create a QA branch. From QA, create a Development branch. Finally from QA, create a bug-fix branch. Why not fix the bug in the development branch directly and merge (RI) these fixes to QA and then to Production. Or why not fix the bug directly in the QA branch, since this branch is separate from the Production branch. Why have all these merges? And how does a bug fix get back to the Development branch?

Finally, How does the Branch by Quality pattern support multiple releases? There are no Release branches in this pattern. There is only one Production branch (as the top-level parent to all the other branches).

The rangers branching guidance always allows for the possibility of multiple releases by having all release branches be children of Main (or QA), rather than the other way around. Whenever you have the possibility of 1-many branches (for example, 1 Main branch to many Release branches, or 1 Main branch to Many Development branches, the Singleton or Main branch should be the parent in the branch structure. You cannot not have a Child branch with multiple parents But you can have a parent (Main) with multiple children (Development, Feature, Release, etc).

This a is a fundamental concept that is always resolved in the same way in all of the various Ranger branching patterns. Start with Main... create as many development branches as you need, when you need them as children of Main. Create as many Release branches as you need when you need them, also as children of Main.


Bill Heys
VS ALM Ranger


Feb 23, 2011 at 9:00 AM

Thank you - this is a longer and more detailed response than I hoped for (I'm still  reading it).

You should consider including the "branch-by-release" as an anti-pattern in the next guidance -- it's almost the complement of the "single team branching model" (scenario 1). MAIN acts as the development branch, and RELEASE branches appear as needed for stabilization.

And yes - this does lead to feature work and QA colliding on a single branch. This results in feature work slowing down or stopping during QA cycles. As we near release, the pace of checkins on the MAIN slows, and QA picks over the result with a fine-tooth comb, often with the devs helping our with QA. The code-freeze effect definitely affects us.

Lots of things to consider - thanks again.


Feb 23, 2011 at 12:32 PM

We do not have a list of anti-patterns in the Rangers' Guidance. There are several widely-circulated white papers which include lists of anti-patterns. We chose to take a somewhat different approach. For example, in the popular book "Design Patterns: Elements of Reusable Object-Oriented Software" by Erich Gamma, et al, they provide a "catalog" of recommended patterns. But I don't believe they have a catalog of anti-pattterns. Of necessity there are probably many patterns for branching we could include in the Rangers' Guidance. Some are good and some are problematic. We chose to present a small number of patterns, starting with the basic plan and growing in complexity. Our thinking was that a large percentage of TFS users would be able to adapt one of these patterns to their use. We will continue to offer some good principles for good branching structures, some of which are in my response here (for example - why is Main the parent of Development, and not the other way around)

Bill Heys
VS ALM Ranger

Feb 23, 2011 at 12:44 PM

I suppose you could say that most branching patterns I have seen in various whitepapers, including the three "branch by release" patterns discussed in this series in Visual Studio Magazine are in one way or another "anti-patterns"

Patterns which provide a robust release strategy and a weak development strategy (Branch-by-Release: "Most development happens on the Main line of code") are certainly anti-patterns from my perspective.

Likewise the Branch-by-Quality, for reasons I described in an ealier response to your question is clearly another anti-pattern. Crazy merging as result of a crazy branch structure on the development side.

Bill Heys