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

Need guidance on branching setup

Oct 26, 2011 at 9:58 AM

Hi all, we need a little guidance on our branching setup

  • We have a single client who always uses our latest code.
  • We have a maintenance team who makes about 5-10 software releases throughout the year.  (5 developers)
  • The maintenance team may also need to make an emergency fix to a release at any point in time (happens 2-3 times per year)
  • We have a development team who makes a major release every year or two. (12 developers)

I am thinking we use something like the the Basic Branch plan.

Main Branch

  • built daily,
  • no direct check ins.
  • base fo all other branches

Release Branches

  • For the maintenance team.
  • Based on Main Branch,
  • CI Build,
  • New Branch for each version of code.
  • Pushes to Main every couple of days when code is stable.
  • Production release direct from the release branch
  • Branch is made read only after release

Development Branch

  • for the development team. 
  • Based on Main Branch,
  • CI Build. 
  • FMerge updates from Main every day or two
  • When ready to release, they get latest production release from Main; their branch will effectively become a release branch


(1) any improvements to the above setup for our sceanrio?

(2) who does the mergeing between branches the developers or the config manager?

(3) we might have a couple of maintenance releases on the go at once and require a fix to the current deployed release.  E.g.

1.3 is in production.  Release branch 1.3 is read only
1.4 is under development by the maintenace team with most items being QA tested
1.5 is under development

In this case, we need to make a fix to the 1.3 branch that has the software in production - do we open that old branch, fix and release or create a new one?










Oct 26, 2011 at 2:09 PM

I agree with almost all of your points.

With respect to the Development branch, when ready to release.:

  • Merge (Forward Integration) from Main to Development. Resolve any integration conflicts in the development branch.
  • Merge (Reverse Integration) from Development to Main - stabilize the code in Main (deploy from Main to QA environment)
  • When Main is ready to release, branch Main to a new Release branch
  • Release from the Release branch

With respect to who does merging, it should be someone who is familiar with the code so they can resolve merge conflicts effectively and correctly. This could be a developer, team lead, configuration manager.

If you have the need for post-release sustained engineering (your last question), you might consider the standard branch plan, where you have a servicing branch between Main and the Release branch (for release 1.3, for example). This allows you to keep the release branch read-only while having a branch available for hot fixes.

Bill Heys
VS ALM Ranger



Oct 26, 2011 at 2:16 PM

With respect to your description of the Release branches:

You create the Release branch for a new version after it has been stabilized in Main. When this branch is created, it is made read-only. Therefore, there is no need to have CI builds on this branch. You also do NOT merge again from Main to Release after the Release branch is created. This is an important concept. If you just released version 1.3, Main might be used to stablize version 1.4. Since Main has a different version of the code from the 1.3 release branch, merging from Main to Release 1.3 will *pollute* the vCurrent Release branch with vNext code.

The important point here is one of timing. The scenario you describe suggests creating a release branch and *then* stablizing the code. The scenario I describe stabilizes the code in Main and *then* creates the Release branch.

I am a little confused by the distinction you make between version 1.4 (changes made by the maintenance team) and version 1.5 ( changes made by the development team). As I see it, the maintenance team makes emergency hot fixes to release 1.3 in a servicing branch for version 1.3. The devlopment team would be developing vNext (release 1.4).

Bill Heys
VS ALM Ranger

Oct 26, 2011 at 4:30 PM

Bill, thank you very much for the quick reply.  I like your ideas for the development branch.  They will work for us.

To help clarify - we have two teams:

  1. Maintainers who work only in the release branches. They do minor releases/fixes every couple of months. 
  2. Developers working on a major new release.  These developers work in the developer branch.  THey release code once every year or so.


I'll try to stay away from words that confuse the two.

Our intention is that a release branch is (e.g. 1.1) is created from Main read write, whereby the maintainers do a series of bug fixes and small features. The maintainers check in their code to the release branch.  Since there are up to 5 maintainers writing code in the release branch it would be worth while to have CI and test on this branch.  This release branch would periodically update Main when the code was stable (e.g. when there is a release for QA).  When the last change is made in the Release branch, we use the last build for production (which has been fully tested) and make the release branch read only. For audit and compliance.

Sometimes we will have two releases branch in play.  To further the sample above (with improved wording): 

  • Release 1.3 is in production so the release 1.3 branch is read only.
  • Release branch 1.4 might have most of the work completed perhaps being in its user testing cycle.  It is still read/write and some of the maintainers are doing work in here.
  • A new release 1.5 branch might be starting with new future small features and bug fixes.   It is read write and maintainers are actively checking code into this branch.

In this case, the 1.4 release branch continues to update Main (as changes are verified) and release 1.5 branch pulls from Main.  The release 1.5 branch will not push to Main until after release 1.4 is complete and in production.


Does this clarify things?  Can we make improvements to this idea?


thanks again for the help



Oct 26, 2011 at 4:54 PM

Here is my suggestion:

In the standard branch plan, on the release side, you have two branches per release (for example v1.3 or vCurrent).

Both of these branches are created at the same time (Main ->Servicing; Servicing-> Release). This structure allows for post-release engineering of *unplanned* fixes. These fixes would be made (checked-in) to the Servicing branch, tested and released from this branch. Since they are minor fixes and emergency hot fixes, it is not necessary to make a read-only copy of every emergency release done here. The Release branch would be made read-only immediately after it is created. There would be no merging from Main to any release branches or servicing branches. Hot fixes, on the other hand, would be merged back to main (Reverse Integration) so they could be picked up by vNext development.

Rather than look at v1.4 as a release effort, I would prefer to characterize this as a development branch. This means you would have two development branches, vNext (1.4) ande vNext +1 (1,.5). These two development branches would be siblings. It is a minor distinction perhaps, but I think it more clearly depicts what is going on. Unplanned bug fixes to released code would be checked into a servicing branch for the appropriate release. Planned maintenance work would be checked into a development branch (vNext). Future development would be checked-into a different development branch (vNext +1`).

This approach allows you to maintain stable branches in Main and Release. I think the workflow you describe is not impacted by this semantic change for the Release 1.4 branch. It continues to be read/write with CI. It will periodically merge back to Main so the vNext +1 branch can pick up these changes from Main.

Until they release, 1.4 and 1.5 should be considered development branches. When ready to release, do a final merge of v1.4 development to Main (after merging Main to v1.4 and testing the integration in the v1.4 development branch). Do a final QA stabilization of v1.4 in Main and then make the two relase branches (servicing and release). Make the release branch read only.

Later when v1.5 is ready to release follow the same process as for v1.4.

I hope this helps.


Bill Heys
VS ALM Ranger

Oct 26, 2011 at 9:32 PM

Bill, now I understand.  I reviewed this with the team leads and we are in complete agreement - thank you very much the help.