It’s generally accepted to not edit existing migrations if that migration has been shared or deployed and potentially run in another environment.
That said, is it a good idea to consolidate any migrations which affect the same table before merging your feature branch into master?
I think it makes perfect sense to do this, if the migrations are fixes, reverts, or conceptually related. On the other hand, I wouldn’t consolidate migrations which only happen to touch the same table, but are conceptually separate things. Naming a class DoThisAndThat (as would be likely in that case) feels wrong in any context, but maybe there are benefits I don’t know of which make always consolidating migrations on the same table the better practice.
I am generally of the opinion that this maintenance of the migrations isn’t worth it, its additional time and attention and I don’t think I’ve ever had a problem that consolidation of migrations would have solved.
I’ll disagree with Chad slightly and say that I’d rather see one sensible migration get merged in from a branch rather than a few “wrong turns” that you took before figuring out what you really wanted.
I’ll edit and rerun a migration until it’s merged into master. Once a migration is merged into master, I never touch it.
If you “consolidate” a migration, it actually means that you either redefine an existing migration ID, or you have more than one migration ID that does the the same thing. This makes it more confusing to understand which migrations have and haven’t been run on production without adding any real benefit. Since we’re all using schema.rb now to bootstrap new databases, you rarely run the very old migrations anyway.