Slightly confusing question. Unless you are employing a migrations tracking tool like Phinx, you are left to your own devices. As for DB migrations with EE, there isn't any easily deployable tools for us. It's slightly annoying. Here is a general workflow:
- Test on local developer instance of site making code and database schema changes.
- Make schema changes to target (staging or production) server, then push code.
- If reversion is required, rollback your deployed branch on target, and undo schema changes manually (delete Channel, delete Field Group, etc...)
The key to this system is to be additive until your current task is complete and in place, and only then should you remove any unused tables or columns. The idea is that if you have to develop a new iteration of an appliance already in place and in production, but it requires schema changes, simply add new columns/tables to accommodate your new iteration of this appliance. Then once it's complete, import your data from the old appliance tables into the new one, and then point all old references to the old appliance towards the new one. Then you can safely remove the old version's database columns / tables.
BUT, for the future... if you need to be extra careful between local and staging, simply export your target's database as a backup before making any schema changes. Then if it goes ary and you don't know what tables and columns and rows to manually remove, you can simply import your backup.