First of all, you need to recognize that there are two workflows here: yours and your client.
Your Workflow
- Receive PSD
- Code HTML/CSS
- Code WordPress template
- Deploy theme to live WordPress site
Their Workflow
- Devise required changes and email you
- Write posts
- Upload photos
The Issue
Implementing version control here has absolutely nothing to do with your clients’ workflow. It’s all about keeping track of the code you use for the WordPress theme. All of your theme files, custom plugins, etc should be in a version control system (Git, Mercurial, Subversion, or whatever you choose to use).
Your workflow then becomes:
- Write code
- Commit changes to version control system
- Push changes to production site
- Get comments back from client
- Write code
- Commit changes
- Write code
- Commit changes
- Push changes to production site
Remember, this is about maintaining a version control history for your code. Code is something your clients shouldn’t be changing – and you should never change the code on a production site while it’s in production.
But changes to content (posts, photos, etc) are outside the scope of your version control system. In other words, you don’t make changes in development and then push the database out to production. That’s a poor development practice. If you need the dev and prod databases to be in-sync, then you should routinely pull a backup from the production box and restore your local version from that backup.
Code changes flow from development to production.
Database changes flow from production to development.