If you continue with Liquibase, the best way to deal with this is to fix your changelog so that the problem doesn't happen again. Unfortunately, when the scenario you described happens, the database can be left in an uncertain state, which is why it is considered a 'best practice' to limit changesets to a single change.
The recommendation when using Liquibase is to test your database deploy process in development, then in test, then in staging, then in production. If you are disciplined about not allowing changes in the different environments except through Liquibase, by the time you get out of development you will typically have found the issues like this and when you get to later environments deploying your database changes becomes completely routine.
You can also use preconditions to check whether some condition is true or not, and then only apply the changeset in one of those cases. I feel like that is a 'code smell' that is best avoided if possible.
If you would consider looking at Datical DB, then we have written extensions to Liquibase that make these kinds of workflows more automated. For example, we have a command "deployOrAutoRollback" that does what you are looking for. We have also extended Liquibase to support more database object types, a rules engine that can help automate the checks your DBAs might be doing, and many other features.
Steve Donie
Principal Software Engineer
Datical, Inc. http://www.datical.com/
Steve Donie
Principal Software Engineer
Datical, Inc. http://www.datical.com/