title: How am I supposed to manage db revisions alongside codebase revisions?
body: <p>We have a Rails app with a PostgreSQL database. We use <code>git</code> for version control.</p>
  
  <p>We're only two developers on the project, so we both have to do a little of everything, and when emergencies arise we often have to drop everything to address them.</p>
  
  <p>We have a main branch (called <code>staging</code> just to be difficult ) which we only use directly for quick fixes, minor copy changes, etc. For bigger features, we work on independent feature branches.</p>
  
  <p>When I work on a feature that requires changes to the database, I naturally have to create migrations that alter the schema. Let's say I'm working on <code>feature-emoji</code>, and I create a migration <code>20150706101741_add_emoji_to_users.rb</code>. I run <code>rake db:migrate</code> to get on with my work.</p>
  
  <p>Later, I'm informed of some bug I need to address. I switch to <code>staging</code> to start work on it; however, now my app will misbehave because the db schema does not match what the app expects. So <em>before</em> doing <code>git checkout staging</code>, I have to remember to do <code>rake db:rollback</code>. And then later when I switch back to <code>feature-emoji</code>, I have to run <code>rake db:migrate</code> again.</p>
  
  <p>This whole flow is sort of okay-ish when dealing with just two branches, but when the <code>git rebase</code>s and <code>git merge</code>s happen, it gets complicated.</p>
  
  <p>Is there no better way to handle versioning of code and db in parallel? Or am I doomed to have to run annoying <code>rake</code> tasks every time I want to change branches?</p>