Question on the Basic Branching Model

Question from customer:

“I am very new to this branching  concept and try to understand.  I am not able understand the difference between the Single release vs. single team branching. Can someone help in knowing the difference.”

Response:

I like to think of branching for development separately from branching for release. The Main branch is where these two aspects of software development come together.

Single Team branching is a development branching strategy. If you start with the Main branch and you want to begin development of the first (or next release) of a software application (or product, or system), then you would create a branch for development. If you have only a single team developing all of the features for this next release, you would only need a single development branch. You would branch Main -> Development. Main would be the parent branch and Development would be a full child of Main. Generally you would branch the latest version of Main when you do this. When I use a shorthand notation for branching, I start with a $ to represent the root node of my Team Project Collection (in TFS 2010) or my server (in TFS 2008). The next would be the name of my Team Project (for example a Team Project, ABC would be $\ABC in shorthand). If I have a branch, Main at the root of Team Project ABC, it would be $\ABC\Main. When I branch Main to Development I might represent this as $\ABC\Main -> $\ABC\Development. In this example, Main is the parent of Development from a branch relationship perspective, but Main and Development would appear at the same level in Source Control Explorer under the Team Project

ABC <-Team Project
    Main < -branch
    Development <- branch

Or I could have branched Main to Development in a slightly different way ($\ABC\Main -> $\ABC\Dev\Development). Note the extra node in this branch operation. This means that the branch, Development would be contained inside a folder, Dev, within Team Project ABC.

ABC <- Team Project
    Main <- branch
    Dev <- folder
        Development <- branch

In the preceding example, Main is still the parent, and Development is still a full child of Main.

If you need to support multiple teams for development, you could create one or more additional development branches ($\ABC\Main -> $\ABC\Dev\Development2 and $\ABC\Dev\Development3). Each of these additional development branches would be full children of Main and would therefore be siblings of each other.

On the release side, Single release simply means I only need to support one current release of my software product (or system, or application). The Release branch is created from Main at the end of the development process, after the code has been stabilized (in Main), passes QA Quality gates, and is deemed ready to ship. At this point, you branch Main to Release ($\ABC\Main -> $\ABC\Release or $\ABC\Main -> $\ABC\Release\Release1).

This would give you:

ABC
    Main
    Dev
        Development1
        Development2
        Development3...
   Release
        Release1

If you need to support multiple releases, then you add complexity on the release side. For example you may have two Release branches (Release1, Release2) where you are actively doing bug fixes of released code, while at the same time your development team(s) is working on Release3. In this example, I use vCurrent to represent the latest production release (Release2), and vCurrent -1 to represent one prior release (Release1) that you need to support. And Release3 is vNext - being developed and not yet released.

The bottom line you can have a very simple model (one Main, one Development, and one Release branch), or you can add complexity to the Development side (multiple feature teams) or you can add complexity to the release side (multiple Release branches). But adding complexity to the Development side does not necessarily mean you have to add complexity to the Release side and vice versa.