The migrations table records a batch number rather than a position, and migrate:rollback unwinds the highest batch — which is every migration that ran in the last migrate command, not the last file. “Undo one migration” is not an operation the tool offers, and finding that out on a shared staging database is the expensive way.
$ php artisan migrate
Migrated: 2013_11_26_141002_create_shipments_table
Migrated: 2013_11_26_141130_add_carrier_to_orders
$ php artisan migrate:rollback
Rolled back: 2013_11_26_141130_add_carrier_to_orders
Rolled back: 2013_11_26_141002_create_shipments_table
$ php artisan migrate --pretend
CreateShipmentsTable: create table `shipments` (...)Two migrations that went in together come back out together. If only the second one should go, the tool will not do it, and editing the migrations table by hand to fake a batch number is how environments end up disagreeing about the schema — write the reverse as a new migration instead. The other half of this is that a down() nobody has ever run is a down() that does not work; dropping a column is easy to write and easy to get subtly wrong, and migrate:refresh on a local database is the only thing that ever exercises it. --pretend prints the SQL without executing it, which is the cheapest possible review for a migration aimed at a database with data in it.