Most people will want to skip this rule and just work on the dev branch.
But, most of the time this is because branching and merging suck in
most version control systems. Exploring new functionality in a branch
has a lot of benefits:
- ``OMFGWTFBBQ that feature is sooooo cool.'' It's so cool you've
decided to push it live ahead of all those other whozeywhatsits you've
been working on. This is a non-issue if you've worked it out in it's
own branch. Just merge it with production when you're ready to go
and you've got no worries about other things coming along for the
ride.
- ``Ok that sucked.'' You thought it would be cool but it just ended
up being lame, or breaking more things than you feel like dealing
with, or whatever. You're not keeping it. If you worked it out on
it's own branch you're done. It's not messing with anyone else's code.
It's not in the trunk. Just walk away. If you were working on the
trunk you'd have to roll back all those changes.
- ``It's good but it can wait.'' Sometimes this means wait till
the next push, in which case you just merge it into the dev branch.
Sometimes this means you need to shelve it for a couple months and
wait for some other major newness, in which case you'll be quite relieved
you weren't working this out the development branch. Again, you're
done. Just walk away. A couple months from now when you're ready to
use it you can merge it into dev. Yeah that merge may be a pain because
of all the other changes that will take place in the interim but it's
less of a pain then trying to juggle keeping it in the dev branch
and needing to work around it.
K. Rhodes
2007-05-18
