Example Clean Trunk Branching Strategy

I was cleaning up the files on my laptop the other day and came across a document I used a few years ago to explain our Code Repository Branching strategy.  I figured I would share it in a post.

The scenario was a group of 4 different development pods of about 5-6 developers in each.  We pushed code out about 2-3 times a week.  We worked within SVN.  The strategy we used allowed for one development pod to work on longer features for say 2 weeks while another was able to work on shorter features for say 2-3 days.  Whenever the development pod was done they would merge up and release out.

The approach is also referenced as a clean trunk approach.  This means that we kept trunk clean at all times.  In the case below Beta testing is done against a Release Branch.

Branching Strategy

In this example we used someone we called a “Production Coordinator”.  This person was our gatekeeper so to speak.  He dictated when a team could merge, when code was released and so forth.  This person was more of a scheduler and traffic director then an architect who was doing reviews.

The top line is our TRUNK line.  The second line underneath it is our RELEASE BRANCH line.

In the above diagram:

  1. Starting Phase
    1. Pod team merges code from TRUNK to their POD BRANCH
  2. Development Phase
    1. Pod developers dev and commit against POD BRANCH
    2. Alpha testing is done on POD BRANCH by Alpha QA
  3. Candidate Phase
    1. Dev Lead and PM decide that they have a candidate for release.
    2. Product Manager signs off on features for the release
    3. QA team performs test plan and gives signoff
    4. Schedules release with Production Coordinator
  4. Release Branch Phase
    1. Production Coordinator gives go ahead for Release Candidate from step 3
    2. Dev Lead merges the Release Candidate into the RELEASE BRANCH
    3. QA team performs test plan and gives signoff
  5. Production Release Phase
    1. Dev Lead merges the RELEASE BRANCH into TRUNK
    2. QA team performs test plan and gives signoff
    3. Production Coordinator pushes RELEASE BRANCH to production
    4. QA team performs test plan and gives signoff
  6. Post Launch Phase
    1. Dev Leads from other dev pods merge down from Trunk to get latest release


This is by no means a perfect solution.  Since then I have used several other branching strategies to varying degrees of success.  The key lesson that I have learned is that you need a documented strategy in place and you need to abide by it.  Revise it as appropriate to improve it.

Posted in , and tagged , .

Leave a Reply

Your email address will not be published. Required fields are marked *