Take the 2-minute tour ×

The company I work for is starting to have issues with their current branching model and I was wondering what different kinds of branching strategies the community has been exposed to?

Are there any good ones for different situations? What does your company use? What are the advantages and disadvantages of them??

share|improve this question

closed as not constructive by casperOne Feb 24 '12 at 19:53


Read this classic: oreilly.com/catalog/practicalperforce/chapter/ch07.pdf –  zvolkov Apr 15 '09 at 23:41
@casperOne that's probably the funniest way to handle a link-only answer flag I ever seen –  gnat Feb 24 '12 at 20:48
@gnat Comes part in parcel with handling the flag on the answer. =) –  casperOne Feb 24 '12 at 21:13
I think this is a very good Q and should not be closed as NOT CONSTRUCTIVE. –  hsalimi Jul 13 '12 at 10:10

17 Answers 17

Here is the method I've used in the past with good success:

/trunk - bleeding edge. Next major release of the code. May or may not work at any given time.

/branches/1.0, 1.1, etc. Stable maintenance branches of the code. Used to fix bugs, stabilize new releases. If a maintenance branch, it should compile (if applicable) and be ready for QA/shipping at any given time. If a stabilization branch, it should compile and be feature complete. No new features should be added, no refactoring, and no code cleanups. You can add a pre- prefix to indicate stabilization branches vs maintenance branches.

/branches/cool_feature. Used for highly experimental or destructive work that may or may not make it into trunk (or a maintenance branch). No guarantees about code compiling, working, or otherwise behaving sanely. Should last the minimum time as possible before merging into the mainline branch.

/tags/1.0.1, 1.0.2, 1.1.3a, etc. Used for tagging a packaged & shipped release. Never EVER changes. Make as many tags as you want, but they're immutable.

share|improve this answer
In your branches/cool_feature folders, do you branch the whole trunk or just certain sub-folders? –  swilliams Sep 12 '08 at 16:42
typically it's the whole trunk. rarely does a feature only touch one directory. i also highly recommend svnmerge.py if you aren't running svn 1.5. makes the whole branch/merge process much nicer. –  jcoby Sep 12 '08 at 16:48
You present a very good well though out model. A policy that my company enforces, and I think this is fairly common, is that the trunk should always build and pass all test. So you say under your model that it 'may or may not work'. There are varying degrees of stabilization, and I think that enforcing the rule that the trunk should always build and automated tests should always pass is a good rule in general. –  RjOllos Sep 11 '09 at 7:56
If you use branches to "stabilize new releases", then how do you (continuously) build and (automatically) test it? For me what is essential about trunk is that it is the version that is (continuously) build and (automatically) tested after each commit. I think one should stabilize a release within a trunk and use branches for both future and past versions, whereas trunk should be for the current. And if it is possible to (continously) build and (automatically) test all the branches, then trunk is not needed at all. Am I right? –  Michal Czardybon Nov 15 '11 at 8:22

I'd highly encourage reading Eric Sink's opinion on the matter:

Chapter 7: Branches

I, like Eric, prefer the "folder" style branching that he talks about.

share|improve this answer
Eric said: "Simple changes. As I mentioned above in my "Eddie" scenario, don't branch for every bug fix or feature." But with new SCMs out there, this is not true anymore. SVN guys used to say the same until they implemented proper branching... And GIT folks will never say that... But usually people behind a certain version control will say what they can't do is not worth doing... :-( –  pablo Apr 27 '09 at 22:46
Eric is revising the HOWTO, and I believe he's even making it into a book. The popularity of systems like git and hg is a topic in some of his most recent blog posts as well. –  Ryan Duffield Apr 28 '09 at 15:09

For the mother lode on branching patterns see Brad Appleton's Streamed Lines: Branching Patterns for Parallel Software Development. It's heavy duty but I haven't seen anything to surpass it in terms of breadth and depth of knowledge about branching.

share|improve this answer

Our repository looks like:


/trunk is your standard, bleeding edge development. We use CI so this must always build and pass tests.

/branches this is where we put 'sanctioned' large changes, ie something we KNOW will make it into trunk but may need some work and would break CI. Also where we work on maintenance releases, which have their own CI projects.

/sandbox each developer has their own sandbox, plus a shared sandbox. This is for things like "Lets add a LINQ provider to our product" type of tasks that you do when you are not doing your real work. It may eventually go into trunk, it may not, but it is there and under version control. No CI here.

/vendor standard vendor branch for projects where we compile but it is not code that we maintain.

/ccnet this is our CI tags, only the CI server can write in here. Hindsight would have told us to rename this to something more generic such as CI, BUILDS, etc.

share|improve this answer
  1. One branch for the active development (/main or master, depending on the jargon)
  2. One branch for each maintenance release -> it will receive only really small fixes, while all major development goes to /main
  3. One branch for each new task: create a new branch to work on every new entry on your Bugzilla/Jira/Rally. Commit often, self document the change using inch pebble checkins, and merge it back to its "parent" branch only when it's finished and well tested.

Take a look at this http://codicesoftware.blogspot.com/2010/03/branching-strategies.html for a better explanation

share|improve this answer

The first thing: KISS (Keep it simple stupid!)

  /RB-1.0 (*1)
  /RB-1.1 (*1)
  /RB-2.0 (*1)
  /REL-1.0 (or whatever your version look like e.g. *2)
  current development with cool new features ;-)

*1) Keep version maintainable - e.g. Service Packs, Hotfixes, Bugfixes which may be merged to trunk if necessary and/or needed) *2) major.minor.build.revision

Rules of the thumb:

  1. The Tags folder need not to be checked out
  2. Only few coding in release branches (makes merging simpler) - no code cleanup etc.
  3. Never to coding in tags folder
  4. Never put concrete version information into source files. Use Place-holders or which the build mechanism will replace by the version number you're building
  5. Never put third party libraries into your source control (also no one will add STL, MFC etc. libraries to SVN ;-))
  6. Only commit code that compiles
  7. Prefer using environment variables instead of hard-coded paths (absolute and relative paths)


share|improve this answer

We use the wild, wild, west style of git-branches. We have some branches that have well-known names defined by convention, but in our case, tags are actually more important for us to meet our corporate process policy requirements.

I saw below that you use Subversion, so I'm thinking you probably should check out the section on branching in the Subversion Book. Specifically, look at the "repository layout" section in Branch Maintenance and Common Branch Patterns.

share|improve this answer

The alternative I'm not seeing here is a "Branch on Change" philosophy.

Instead of having your trunk the "Wild West", what if the trunk is the "Current Release"? This works well when there is only one version of the application released at a time - such as a web site. When a new feature or bug fix is necessary a branch is made to hold that change. Often this allows the fixes to be migrated to release individually and prevents your cowboy coders from accidentally adding a feature to release that you didn't intend. (Often it's a backdoor - "Just for development/testing")

The pointers from Ben Collins are quite useful in determining what style would work well for your situation.

share|improve this answer
We used to have this model, but the constant merging back of changes from the branches turned out to be prohibitively complex. Now we use trunk for bleeding edge, and branches for stabilization and maintenance. This way no merging of trees is needed. –  Joeri Sebrechts Oct 24 '08 at 11:01

Henrik Kniberg's Version Control for Multiple Agile Teams also has some good points to take into consideration.

share|improve this answer

We currently have one branch for ongoing maintenance, one branch for "new initiatives" which just means "stuff that will come out sometime in the future; we're not sure when." We have also occasionally had two maintenance branches going on: one to provide fixes for what is currently in production and one that is still in QA.

The main advantage we've seen is the ability to react to user requests and emergencies more rapidly. We can do the fix on the branch that is in production and release it without releasing anything extra that may have already been checked in.

The main disadvantage is that we end up doing a lot of merging between branches, which increases the chance that something will get missed or merged incorrectly. So far, that hasn't been a problem, but it is definitely something to keep in mind.

Before we instituted this policy, we generally did all development in the trunk and only branched when we released code. We then did fixes against that branch as needed. It was simpler, but not as flexible.

share|improve this answer

We branch when a release is ready for final QA. If any issues are discovered during the QA process, the bugs are fixed in the branch, validated and then merged to the trunk. Once the branch passes QA we tag it as a release. Any hotfixes for that release are also done to the branch, validated, merged to the trunk and then tagged as a separate release.

The folder structure would look like this (1 QA line, 2 hotfix releases, and the trunk):








share|improve this answer

Jeff Atwood wrote about this in a good blog post; that post has got some important links in it.

share|improve this answer

Gnat has written this excellent break down on the various bits of advice your can find on branching strategies.

There's not one branching strategy, it's what works for:

  • Your team size
  • Your product and the lifecycle periods
  • The technology you're using (web, embedded, windows apps)
  • Your source control, e.g. Git, TFS, Hg

Jeff Atwood's post breaks down a lot of possibilities. Another to add is the concept of promotion (from Ryan Duffield's link). In this setup you have a dev branch, test bracnh and release branch. You promote your code up until it reaches the release branch and is deployed.

share|improve this answer

The philosophy that we follow at work is to keep the trunk in a state where you can push at any time without drastic harm to the site. This is not to say that the trunk will always be in a perfect state. There will of course be bugs in it. But the point is to never, ever leave it broken drastically.

If you have a feature to add, branch. A design change, branch. There have been so many times where I thought, "oh I can just do this in the trunk it isn't going to take that long", and then 5 hours later when I can't figure out the bug that is breaking things I really wished that I had branched.

When you keep the trunk clean you allow the opportunity to quickly apply and push out bug fixes. You don't have to worry about the broken code you have that you conveniently branched off.

share|improve this answer

This would depend on which Version Control System you're using. Each VCS has different approaches to branching.

Which VSC do you use?

share|improve this answer
While the version control system might determine how you go about branching, it does not necessarily determine your branching strategy. To answer your question though, we use subversion. –  Craig H Aug 29 '08 at 18:47
I'm not sure that's entirely true in practice. Git practically encourages branching because it's an easy and quick operation and merging it relatively straight-forward. It's much harder in CVS. Not making a branch because it's hard work would form part of a branching strategy. –  Stephen Darlington Oct 24 '08 at 11:03

For Subversion, I agree with Ryan Duffield's comment. The chapter he refers to provides a good analyses on which system to use.

The reason I asked is that Perforce provides a completely different way to create branches from SVN or CVS. Plus, there are all the DVCSs that give it's own philosophy on branching. Your branching strategy would be dictated by which tool(s) you're using.

FYI, Svnmerge.py is a tool to assist with merging branches in SVN. It works very well as long as you use it frequently ( every 10-30 ) commits, otherwise the tool can get confused.

share|improve this answer

No matter which branching pattern chosen, you should try to keep your branches in a binary tree form like this:

   trunk - tags
   /  \  \
bugfix  f1  f2
        /   \  \          
       f11    f21 f22
  • Child nodes should only merge with the direct parent.
  • Try ur best to merge only the whole branch with the parent branch. never merge subfolders within a branch.
  • You may cherry pick commits when needed as long as you only merge and pick from whole branch.
  • The next branch in the above figure is only for illustration, you may not need it.
share|improve this answer
