The idea behind migrations is that a developer has a local database that is based on the shared schema (in production and on other local databases). If they want to change the schema, they can do a pull of master, branch out, change their dev DB by creating migration(s), and another dev can then check out the committed migrations / code in THEIR local system before approving the PR, so you can evaluate DB changes before affecting production systems. In the absence of a production DB with important data, the schema file is all you need to jump-start your system.