Database version control methodology?

The main idea is to find a standard way to version control the Exasol database (schemas and their objects) using Git and also incorporate version control workflow methodologies like Gitflow (https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow).

The project structure should include two parts - the database object code (DDL and any config-like table content, e.g. mapping table or alike) and change scripts.

The database code of each db object (schema, table, view, script and function) is stored in individual sql files and organised in a directory three that resembles the object three in a database client:

Databases
└─ Schemas
      ├─ Tables
      ├─ Views
      ├─ Script
      └─ Functions

The changes are scripts necessary to take the database from state X to state X+1 or to revert from X+ 1 back to X. A tool like Liquibase could be the solution here.
There should be a way to capture end state of the database code after rolling out the change X and update the database.

This way a single commit to the version control system (e.g. Git) will contain an atomic change and will also capture the end state of the objects that are subject to change.

My research so far only suggests the following combination:
- Database client (DataGrip, officially supporting Exasol)
- Project directory structure dictated by the database client that incorporates the above-mentioned directory structure + directory for change files
- Database introspection mechanism that can synch local DDLs and DMLs with the database
- Version control system (Git) integration that supports the desired branching strategy (Gitflow)

If a tool does not support all these in one package then the weak point is that even if introspection is implemented via set of custom scripts, then the developer has to remember to synch the local DDLs and DMLs via manual introspection step.

Any ideas?