My comments are based on the Friday, August 24, 2012 version of the Branching and Merging Guide.
I recommend you re-read page 40. Most of your questions are answered there. I pasted the first part below so you can see that it answers most of your questions. Notice that it describes several variants such as :one development area vs multiple development branches; or one release branch (reused) vs one per release. After you re-read this a couple of times. If you still have questions, let us know.
From Page 40
Basic Branch Plan
The basic branch plan with a main, dev, and release branch enables concurrent development for your next release, a stable MAIN branch for testing and a release branch for any ship blocking bug fixes.
Multiple development areas are supported by creating additional development branches from MAIN. These are peers to each other and children of MAIN.
Additional releases are supported by creating additional release branches for each product release. Each release branch is a child of MAIN and a peer to each other (e.g. release 2.0 branch is peer to release 3.0 and both are children of MAIN). If supporting only a single release in production at a time, you may consider a single release branch, and make bug fixes directly on this branch as depicted in the diagram below.
Once the release branch is created MAIN and the development branches can start taking changes approved for the next product release. An even simpler version of this plan for smaller teams might only include a MAIN and RELEASE branch. Consider this if the isolation required only required two branches such as for smaller teams and projects.
I recommend you re-read page 40. Most of your questions are answered there. I pasted the first part below so you can see that it answers most of your questions. Notice that it describes several variants such as :one development area vs multiple development branches; or one release branch (reused) vs one per release. After you re-read this a couple of times. If you still have questions, let us know.
From Page 40
Basic Branch Plan
The basic branch plan with a main, dev, and release branch enables concurrent development for your next release, a stable MAIN branch for testing and a release branch for any ship blocking bug fixes.
Multiple development areas are supported by creating additional development branches from MAIN. These are peers to each other and children of MAIN.
Additional releases are supported by creating additional release branches for each product release. Each release branch is a child of MAIN and a peer to each other (e.g. release 2.0 branch is peer to release 3.0 and both are children of MAIN). If supporting only a single release in production at a time, you may consider a single release branch, and make bug fixes directly on this branch as depicted in the diagram below.
Once the release branch is created MAIN and the development branches can start taking changes approved for the next product release. An even simpler version of this plan for smaller teams might only include a MAIN and RELEASE branch. Consider this if the isolation required only required two branches such as for smaller teams and projects.
