The migration question underneath this is worth separating, because it is where the divergence starts.
Migrations are the only thing that should ever change schema, in either database. If you have ever run an ad hoc alter statement against one of them, they are now different in a way no tool will tell you about, and that is usually the origin of the wrong-database confusion - you are seeing a difference and assuming it is data when it is schema.
So:
Apply migrations to local first, always. That is what local is for. If it fails there, it would have failed in production.
Apply to remote as a deliberate step, ideally from your deploy process rather than from your terminal, so it is recorded and repeatable.
Never edit an applied migration. Add a new one. This is true everywhere and it is especially true when two databases are at different points in the sequence.
Keep seed data out of the migrations directory. This one has bitten people badly: a seed file that lives among migrations gets applied to production the next time migrations run, and if it contains a delete to make it re-runnable, it deletes real rows. Seeds are a separate command, applied only to local, by hand.