[foobarbaz33]

I do something similar.

We use a minified version of the production DB (baseline). People create numbered sql scripts. A helper script will restore the baseline DB on their local laptop, then apply the new sql files against it.

You develop a deployment script explicitly rather than have it generated. Automatic diff-based generation is full of holes. Making a deployment script directly works flawlessly for all all cases: renames, external data imports, flat files, etc.

Feature branches? no problem.

    git fetch
    git rebase origin/master. 

If someone adds a new script you just bump your script number and continue. Scripts are often order-independent, so even if you both make claim to 04_foo.sql it may not matter, and if it does you just bump your script to 05_foo.sql.

I've been using plain old sql scripts for many years with exactly 0 deployment issues. The fact everyone is constantly testing/validating a "deployment" on their local box is a huge win.

With a minified DB the full restore and script deployment can be done in under 10 seconds usually. With big data imports it may take longer, but those scripts can simply be renamed from 80_import.sql to 80_import.sql.SKIP for a faster iteration.