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

Single release vs single team branching

Dec 22, 2010 at 8:58 PM


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

In the single team branch, once a release is done and if a bug is reported are we supposed to fix the bug in the Main branch and forward integrate back to the DEV branch.



Dec 22, 2010 at 9:25 PM

Hi Abe,

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 verision of Main when you do ths. 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 stabilzed (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:


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 developmen 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 complextity 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.

Hope this helps,
Bill Heys
VS ALM Ranger

Dec 22, 2010 at 9:50 PM

Thanks ...

that was a great explanation.

We are looking for the Single Release Plan.




Dec 22, 2010 at 9:56 PM
Edited Dec 22, 2010 at 9:57 PM
abrahamw77 wrote:

In the single team branch, once a release is done and if a bug is reported are we supposed to fix the bug in the Main branch and forward integrate back to the DEV branch.


Again, separating Development from Release, bug fixing a shipped release is a Release question, not a question that is unique to single team (development) branching.

Once you have shipped a release, and branched Main to a Release branch ($\abc\Main -> $\abc\Release\Release1), the Main branch is opened up for stabiling the *next* release (vNext or Release2).

To fix a bug in the current release (vCurrent), you would make that fix in the Release branch ($\abc\Release\Release1) and ship it from there. Then you could merge it back to Main (Reverse Integration) and then to Development (Forward Integration)

Reverse Integration is always a merge from Child to Parent, while Forward Integration is always a merge from Parent to Child.

Bill Heys
VS ALM Ranger