How do I add version control to my workflow?

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.

Read More

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.

Related posts

Leave a Reply

3 comments

  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.