Version Control: developing on branches rather than master/trunk

I’ve changed my mind.  It now seems that it is much more sensible to develop on branches rather than on master or trunk.  What am I on about?

Well software source control or version control systems.  I tend to use two: subversion and git.  Actually, I tend to use git whenever I can including when I have to use subversion. git svn is, in US terms, awesum.  One debate I have had on and off is whether to:

I’ve previously done the former, but I’m rapidly shifting to the latter.  My rather simple reasoning is that I want trunk/master to be, to all intents and purposes, a working copy of the latest software.  i.e. the software that is in trunk/master passes its tests, builds and basically does what it says it should on the tin.  The developing software is done on a branch and only merged back to trunk/master when it passes its tests.  Thus the process is:

  1. Branch
  2. Develop & test
  3. Merge from trunk/master to the branch (i.e. pull any updates)
  4. Test, test, test
  5. Review code with buddy, senior dev, etc. (depending on your set-up)
  6. Merge back into trunk as a finished feature.

Even better, only work on code that is actually described in a ticket, bug, or on something like pivotal.  That way you stay focussed and only spend time on developing features/fixing bugs that the ‘customer’ actually wants.

The only question then is what you do with releases?  My initial guess is to tag them as a release on trunk/master.   Then if you get a bug and have to maintain the old release then to branch at that point and maintain the release as its own ‘master’ release branch.