We pretty much just covered why it's good to start from the production branch but there's a little more to it. People are counting on your site. You can't afford to be ``pretty sure'' you haven't touched anything else in the system when patching the bug. Reading through old check-in logs to see what we've changed is tedious and boring, and lets be honest with ourselves here: we're not going to do it anyway.
Before you touch that bug you're going to make a branch from production to work on it. Remember number five? ``You are not using a version control system that makes branching and merging a pain''. You are going to have the benefit of version control on your changes no matter how small they are. And remember 1b? That means no check-ins to production until they are ready to go and you've still got to check it into the dev branch too. Are you seriously considering trying to merge the live branch into the dev branch? That's just asking for pain. So you start with a branch of production, write the test, fix the bug, merge it in to the dev branch, merge it into the production branch, and deploy. And no, as you've probably guessed I'm not a unit testing freak but you just had a bug make it to the live site that was so severe it couldn't wait until the next push. You can't afford that to happen again so you write a test for it.
K. Rhodes 2007-05-18