It’s a little difficult, which is why you may have never seen a great working example.
For most web apps, it’s generally bad practice to pull in the production database, as you don’t want to be playing around with actual user’s emails, if that is in the DB. So the suggestion is to set up fake data to use in development.
Unfortunately, Wordpress is usually different. Generally we’re setting up a standard website, so all page content basically needs to go into the DB.
I’ve set up a few shell scripts that utilize wp-cli, so myself and colleagues can work on the same project, and if we make changes to the DB, we can dump the DB and have it committed to the repo. It’s not a great way to do it, as every .sql file basically overwrites the last one 100%. But other than including it in the repo, the only other way I can think of that you could “sync” a DB between multiple people’s local dev environment is having a DB externally that everyone connects to.
Something that I may consider in the future, at least for development, is what the Roots site does, and that’s set up static pages outside of the DB. I forget exactly which plugin/tool is used, but when pages are kept in static files, at least they can be tracked with version control.
Amen to that. WP Migrate DB Pro is essential and I personally think that they deserve to be paid to keep up the development, even if it is licensed under the GPL. There are a few WP tools that I pay for and I like to support their continued development.
To be honest I’d be more than happy to pay for a license to use Roots, given that Bedrock and Sage have totally transformed my small business.
In the meantime I’ll continue to show my gratitude by buying screencasts.