How to handle changed database structures in Liquibase when switching between Git branches

Question

Imagine I have a USER MySql table with the rows id, name, email, address in the 'main' Git branch. I create a new feature branch and decide the 'address' column needs to be removed from the USER table and be put into its own separate table. This is done by adding a new changeset to my Liquibase changelog file. I refactor my code afterwards and everything works well!

Now I switch back to the 'main' branch and try to run my code. Everything crashes now, since my code expects there to be an 'address' column in the USER table, but it's not there.

This situation happens often in our codebase. Is there a way to avoid this? Somehow be able to 'roll back' the changesets that are NOT on the 'main' branch?

Answer 1

The comments on this post have some good suggestions for you. There are multiple ways to resolve this issue, and most of them involve changing the way you've organized your databases and branches. Here is a summary of a few of the answers and links to the source.

1. There are many examples available when you search branches database migration on StackOverflow
2. Database migrations in a complex branching system A: "Anyway, the way we handled customer code and branches, was to have a specific DB/schema for a given branch. This way you could have the schema and data from the branching point, and only migrate the diff to the current situation. We did not undo changes, even if liquibase, in theory, could support this, as we felt it was way too cumbersome and error-prone. Given that liquibase keeps its own state, the migration was always as easy as taking the current state on a given branch and apply all. Only new changesets were applied, leaving the schema in a good state."
3. Database migrations in a complex branching system B: "…rebuild the database from a baseline. During initial development, that baseline was an empty database, and during maintenance, it's a copy of the live database (restored from a dump). We just have a pile of SQL and XML scripts that we apply to the baseline to get a current system (migrations, essentially, but not designed to be run incrementally). Updating or switching branches is then very simple: nuke the database, load a dump to establish the baseline, run the scripts."