This project is read-only.

Code Branching

In order to create a stable, uniform process for developing and releasing code for this project, we will employ a simple banching model as demonstrated in the branching guidance provided by the TFS team (see links below). This branching model uses three primary levels: Development, Main, and Release.

The DEVELOPMENT (dev) branches are for next version work.
  • Focus on wide, flat branches to enable steady code flow to MAIN and then back to peer DEVELOPMENT branches
  • Work in DEVELOPMENT branches can be segregated by feature, organization, or temporary collaboration.
  • Each DEVELOPMENT branch should be a full branch of MAIN.
  • DEVELOPMENT branches should build and run Build Verification Tests (BVT’s) the same way as MAIN.
  • Forward Integrate (FI) with each successful build of MAIN
  • Reverse Integrate (RI) based on some objective team criteria (e.g. internal quality gates, end of sprint, etc.).

The RELEASE branch is where you ship your major release from.
  • RELEASE is a child branch of MAIN.
  • Your major product releases from the RELEASE branch and then RELEASE branch access permissions are set to read only.
  • Changes from the RELEASE branch RI to main. This merge is one way. Once the release branch is created MAIN may be taking changes for next version work not approved for the release branch
  • Duplicate RELEASE branch plan for subsequent major releases.

Changes should be checked into one branch only
  • All branches have a merge path back to MAIN.
  • No need for baseless merges



Here is a sample scenario of a branching model for our fictitional Woodgrove Bank:


Related Links

Last edited Jan 24, 2009 at 12:51 AM by rhearn, version 2


No comments yet.