There are open-source solutions out there to migrate database changes and WordPress configuration (WPCFM) in the way you’ve described, but I’m going to answer this by giving insight into the most common practice in a simple scenario.

Updating plugins

Let’s assume all 3 environments are the same except the database on production which has new content. Your dev and stage environment databases might be a bit behind, but it’s essentially the same except for the new content.

First, always make sure you back up your database before starting this process.

1. Commit your plugin updates

While these changes are tracked in git, the updates may have associated database updates that need to be made. Good plugins handle this by checking the current database schema before requiring user action to make database changes, if necessary.

2. Copy the production database to staging

Make sure you change urls and protocols in the database during this process, if necessary.

3. Push plugin updates to staging

Now you have a replica of the production database with the file updates from dev and the latest content from prod. This allows you to test the update process on this environment before moving forward.

4. Deploy live

Now that you’ve tested on a copy of production, you can deploy your changes live and replicate any database changes necessary with low risk.

As an alternative, you could freeze database changes while you’re testing on staging. This would allow you to deploy your database and files at the same time. This isn’t usually feasible since database changes can occur all the time on busy sites. It’s not something I recommend, but it can be necessary in some circumstances.

Other resources

Certainly don’t take my word for it. Do some more research to find the method that works best for you. For Example, take a look at Pantheon’s deployment process.