I read the Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation book by Jez Humble and David Farley. The part that throw me off balance the most was their insistence on using a single branch.

Thinking about it and what they are preaching, it does make sense. But the question is, how to achieve it?.

At my company we are working on C# with TFS as our source control. And the following ideas came to my mind about how to achieve the idea of doing changes that you don't want to release yet, but you want to keep inside the vcs tool:

  • Injections to be able to select the class that you want to use. So you can rewrite some functionality without affecting code that needs to be released.

  • Related, an IoC container to make the above easy to achieve. So you can select at compilation (or even runtime) the ones that you want to use.

  • Decorator pattern to add functionality in a very simple manner (which is just applying the other two above)

At another similar question they talk about the Release Line from Software Configuration Management Patterns (which I still have to read). But the example that they are using deals with tags and creation of branches from them, which doesn't seem to be the same thing as what Humble and Farley talk about.

  1. Do the techniques that I have described sound right for achieving a single branch strategy?
  2. Is there anything else that could be done to manage having your code on a single branch?

1 Answer 1


Multiple developer branches work just as well as a single branch - better in many cases. You might need to use a better tool for the job that TFS, but now it has git backing it that should do fine.

I would not attempt to change the software architecture to suit your build process, its the wrong approach - the software is the thing that matters, keeping it easily maintainable is much more important than suiting some process that is there to serve the software (not the other way round)

The trick with branches is to merge them into the trunk as soon as possible, and not to branch off new work until they are really needed. The other thing to do is to reverse-merge the trunk onto your branches (ie as changes from branches are merged onto trunk, developers working on their branches need to merge these changes to their branch, so they are very closely up to date) Then merging a branch to trunk becomes a trivial task.

Even with code that will sit around an not be merged for a long time, this is still ok - what it does mean is that the merge will become harder to accomplish as time goes on, but no amount of architectural changes to your code will help here - someone makes a change to the codebase and a year later you decide you need that code... I guarantee it won't work properly without manual intervention and refactoring of the code into what the trunk now looks like. What you need to do with this old code is a 3-way diff, so you can see the changes that were made to the original code, and apply those changes (or the important parts of them) to the new branch. Think of bringing the old code to the new as a development task rather than a build manager merging task.

  • Oh, with multiple branches we have no issue. We have been using them for a while, and we have a very stable process working out of them. It is more about the process of a single branch that I'm interested in. How things can work with that single branch, and still be able to keep relaxing fixes, or delaying some work, to promote another one, without breaking anything, in an easy manner. At the time TFS was chosen, I did not have voice or vote (unlike now). Agree that git backing on TFS is a superb idea. Apr 1, 2014 at 12:32
  • Ah, I see.. well, in that case you'll find you cannot. I worked on the "Microsoft model" of Dev branch -> Main -> Release and it worked, just so long as all development was done for tasks that would go on to be part of the build. There is shelving in TFS but I always thought of that as a temporary thing while you worked on something else. You can't cherrypick revisions to merge as you will forget the old ones, if that works at all. I simply would not recommend single branch dev unless you have a small team able to step on each others toes and a very linear dev process.
    – gbjbaanb
    Apr 1, 2014 at 12:38
  • Note that the single-branch concept is very Visual Sourcesafe. I find TFS fits into that mindset a lot, even if it does dress it up with the "innovation" of having 2 or 3 'branches'. (they're more steps than branches in that model)
    – gbjbaanb
    Apr 1, 2014 at 12:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.