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
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,
VS ALM Ranger