How do I add version control to my workflow?

The question:

I develop themes, lots of them. I am given a PSD, code up the HTML/CSS, slap the code into WordPress, and make corrections as they get QC’d. Once live, clients can edit blog posts like normal or upload photos using a custom plugin.

Sometimes I have to make changes to the theme or to the page/post content, which means I either make them live or have to download and setup the site to a development environment to be approved by the client. I have no backup, I have no version control, and I realize this needs to change.

Git and Mercurial have been suggested, and I would like to take advantage of these tools, but I am confused about how to fit them into a workflow.

Do I require all changes to a site on a development server and then push them live once approved? What about writing blog posts? Seems like overkill to write posts on dev and push the changes live, but then how do I sync the databases if they are edited on the live site? I have scoured the internet. Some guidance would be appreciated.

The Solutions:

Below are the methods you can try. The first solution is probably the best. Try others if the first one doesn’t work. Senior developers aren’t just copying/pasting – they read the methods carefully & apply them wisely to each case.

Method 1

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.

Method 2

You can use software that syncs the databases. But there’s also the option of versioning the data itself with something like

Method 3

I just wrote up a thorough answer to this on another question. Personally I use git and it’s fantastic. In terms of getting started with it, I’d recommend checking out and If you’re the book type, I’ve read this one and it’s definitely worth the $22 ebook price. Make yourself do it, you won’t regret that decision.

All methods was sourced from or, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

Leave a Comment