It's fairly common and works pretty well if you have a good test coverage and monitoring in place.

GitHub is a documented example (and I happen to deploy branches daily too :-):

https://github.com/blog/1241-deploying-at-github

I've read several times about github's use of branches in deployment/production. How are DB schema/data migrations handled (and kept safe/sane)? Presumably hubot and friends prevent Bad Things from happening by deploying a branch that doesn't match the current DB state?

I didn't say one way is strictly better. There are tradeoffs to consider and that's all that really matters. I'm not sure it occurred to the OP that there are benefits to forgoing remote branches, so I mentioned it.

My bad, I read "Consider not doing that." as a more strict recommendation!

Sorry, I was too blunt :)

Who said anything about production? Are you saying you've never hit a snag with a local db that had data that would be a pain to re-import?

Keep your database config for the app in version control with the code, and change to another database per branch.

This means your data in that db will diverge from the main branch slightly, but if that is too much of a problem and you need constant updates from live, you could look into migrations like those used by rails, which store your db changes so that they can be replayed on top of newer data from master and bring it up to the new schema. It's quite easy to setup a bare bones migration system using plain SQL migration files and some scripts if this is a problem you see often.

I often work with several branches of code in rails, and it's not a big problem, you just need a system for keeping the data in sync with the code.

Consider forgoing long-lived/significant local branches too then. Branching has its downsides, and avoiding it has some upsides particularly for small teams. As an alternative, you might start using feature flags instead. Look into "continuous deployment" as well for more insight.