Schema Database Version
Not very important - since each Magento module can have its own set of settings / update scripts . If interested, there are tools for managing the database schema, such as dbDeploy .
Database Content Update
Representing the environment as a set of levels, at the top is an intermediate environment, and below (at the same level) are the development environment. All code changes can be performed in any environment, since all environments are just working copies of the same version source code. Each database is captured from the following “tier” environment. So, for example, the dev environment pulled the database out of the staging environment, and when the production environment exists, the staging environment will start from there. Therefore, any changes in the database (for example, updating a product, changing a parameter in the configuration panel, etc.) must be performed at the highest level, and then all levels below this will receive changes the next time they update their database. Now, obviously, during development, you can change as many things as you want to make it work well in your development environment before making these changes above.
How a pulling business works
Pulling (and pushing) the database is pretty simple, mysqldump is executed from the database, then it is searched / replaced (using sed or something similar) with the URL changes, and then imported into the new database.
Having said that ...
Kudos to you that your source code was a version, this at least means that if you need to follow my scenario, you can fully test the module in the development environment before making changes to the production. I wish I could offer more of a specific “solution” - since implementing changes in several environments is certainly not ideal, although I will be interested in what others bring.