This is a proposal for dealing with database migrations when using git (or similiar). The problem with migrations is ensuring that the current state of the database is in sync with the code-base. In practice, this means being able to guarantee that the state of the database correctly reflects the version of the code checked out.
The correct way to build the database schema is to run all db migrations from zero. But as the project grows, this takes longer and longer to execute and quickly becomes inpractical.
To avoid having to re-run all the migrations, it makes sense to have a base sql that avoids running earlier migrations that are relevant to the currently deployed code.
With that in mind, the following is proposed: