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.