In my company we run a java app using a database and we are using Liquibase to manage all changes applied to the database in the development process. The dbchangelog-File and the changesets reside in the git project so that all code and db changes are versioned together in a git commit.
To deploy our app we have a gitops pipeline, so every commit applied to the project are directly propagated to the target environment. As stated above the changesets are also part of these commits and when the changeset has changed liquibase automatically applies all db migrations. AFAIK this is the recommended way to do it with liquibase. All good.
We do a rollback by simply reverting the last commit and the previous version will be propagated to the target env. Technically it means that after the rollback the dbchangelog-File 1 or more changesets will be removed. However, the database still holds the old dbchangelog (and changesets) so it will propably lead to a conflict!?
How are rollbacks supposed to work? I know Liquibase has a cmd line tool to do these kind of things but my goal is to let Git be the single source of truth and therefore manage all this over GitOps or is this not supported?