title: Merge/Branch Strategy
body: <p>We are trying to implement the &quot;Basic Dual Branch Plan&quot; as described by the ALM Rangers in the latest <a href="http://vsarbranchingguide.codeplex.com/" rel="noreferrer">Visual Studio TFS Branching and Merging Guide</a>.  From the guidance:</p>
  <blockquote>
  <p>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.</p>
  <p>Additional releases are supported by creating 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. Once the RELEASE branch is created MAIN and the development branches can start taking changes approved for the next product release.</p>
  </blockquote>
  <p>We are undecided as to whether we want to use a single Release branch (and label releases), or create a new release branch per release.  However, there are some questions that apply either way, that don't seem to be addressed by the guidance.</p>
  <p>My main question is: At what point in time should we create a RELEASE branch (or move tested code to the single RELEASE branch if that's the way we go)?</p>
  <ol>
  <li>My first reaction was to create it only when ready to do the release, but then you have the problem of creating a deadlock for development and testing of the next sprint's work; you cannot check these changes into MAIN until the RELEASE branch has been created (if you do, it's more difficult to separate out the changes you only want to go to RELEASE).</li>
  <li>Second idea is to create the RELEASE branch at the beginning of the sprint, and as changes pass testing in MAIN, merge them down to the current RELEASE branch.  Once we reach the end of the sprint, we can lock that RELEASE branch down, and create a new one for the next sprint.  This sounds like it would work, but I see no discussion of it anywhere, so I just wanted to see what people are doing.</li>
  </ol>