On my development/feature branch, I have a commit with 20150818113106_add_team_id_to_account.rb (which adds a column to Account) & the schema.rb that results from applying the migration. This commit has been pushed, & also exists on origin/development/feature.
Now I want to revert this change- I do not want to add this column to Account after all. I can't work out if I should therefor revert the git commit, or run a db:migrate:down & commit the results of that, or both, or neither.
You've run into a common problem here with rails:
The database state and the program code state are different things.
Try to separate the two concepts.
Normally with code you can just revert unneeded code.
Here however you need to update the database status as well.
If the migration up has already been run there are two options:
Use rake db:down to reverse the migration. This can be a good option if the commit is the most recent one made and the migration to add the column was just run.
Use another migration to remove the column. This can be the cleanest approach especially if the other migration is not the most recent.
If the migration had not been run on your database instance then you could just revert the code commit or in more complicated cases make a new commit to remove the code.
As to which to choose that may depend on whether the migration had been run anywhere else (other than your local environment). If the migration has been run in CI for staging, or pulled for other developers who have run it, then you may wish to choose the 'leave code and add a reversing migration' rather than running the down locally and then trying to revert the code commit. Once the migration has been run elsewhere you're probably better off with original migration, plus another migration (I was going to call this a down migration but that is incorrect, these will be two up migrations) to remove the column with no reverts.