Keeping WordPress Under [Version] Control with Git

Update 6/16/16: In the years since I wrote this blog post, there have absolutely been changes to my workflow. I no longer recommend versioning WordPress core, and prefer to install dependencies via dependency managers like Composer.

Update 9/26/12: Based on some excellent points made by Scott in the comments, I’ve updated the default .gitignore file

Over the last year or so I’ve been deploying my sites and applications almost exclusively through Git. It took a while to get used to, but pushing all of my code through git has forced me to think through my code before committing (lest I get git blame‘d), kept me concentrated on the task at hand, and has made collaborating with other developers so much easier.

There are a number of different ways developers like to keep WordPress sites in Git. Some people commit everything while others may only track the theme(s), excluding core, plugins, uploads, etc. My preferred way of tracking/deploying WordPress sites through Git requires a little configuration; this article outlines my personal WordPress-Git workflow.

WTH is Git?!

I’m assuming (or at least hoping) that all web developers today have at least heard of Git, but here’s the nickel tour: Git is a distributed source-control system developed largely by Linus Torvalds (creator of Linux). Git serves a similar function as other Version Control Systems (VCSs) in that it allows development teams to track code revisions, share code, and manage multiple software versions from a single codebase. Unlike centralized systems (Subversion, CVS, etc.), Git is decentralized; every instance of the repo contains the full history of the project.

Using a system like Git, a development team can easily track changes in projects. As a developer, I can see that Bob added three files to the repo and that Alice changed four lines in one of the stylesheets. I can do a git pull to merge their changes into my local copy of the repo. If next week a site goes down after new code is deployed, I can roll back changes and do a git blame to see when a particular line was changed, who made it, and what other files were changed at that time.

Additional resources

There are plenty of great resources for learning to use Git:

• Try Github: Hands-on training course presented by Code School
• Git Immersion: Git training from New Context (formerly EdgeCase)
• Githug: a fun little command line game that teaches you Git
• My notes from “Using Git for Version Control” at WordCamp Columbus 2012

Using Git with WordPress

When I start tracking a new WordPress site in Git, my first step is creating a .gitignore file in the repo to control what does and, more importantly, what does not get into the repository.

My default .gitignore file looks something like this:

Most of the files are pretty explanatory; We don’t want to keep cache, upgrade, or dynamic sitemaps in our repository. I also like to keep out non-essential files and prevent Desktop Services Store (.DS_Store) or, in Windows environments, Thumbs.DB files from getting committed as they serve no purpose outside of my local environment.

I don’t keep my wp-content/uploads directory in WordPress for several reasons:

1. As soon as a client starts uploading media on production, your repo will be out of date
2. By default, WordPress generates multiple copies of every uploaded image (thumbnail, medium, large). If all of those images are in your repo, everyone who clones it will be downloading every version of every image that’s been uploaded. That means more bandwidth, larger repos, and no real benefit
3. Remember: version control !== site backup. Just like anything else, repos can be deleted, corrupted, or generally messed up. There are plenty of automated ways to backup your site, WordPress-based or otherwise (I’ve been using WordPress Backup to Dropbox on this site and have no complaints).

Up until a few months ago, I would manually FTP the files from production into my local repo (thus preventing my local copy of the site from being broken) whenever I needed to make updates to a site theme. Of course, that got old really quickly so I put together this mod_rewrite rule to simplify the process:

This will check your local wp-content/uploads directory for the requested file and, if it doesn’t exist, attempt to load it from production (obviously you’ll need to replace stevegrunwell.com with your domain/paths in the above snippet). This makes it easier to work on a local copy of a production site since you won’t need your own copy of the wp-content/uploads directory.

You may have noticed that I keep wp-config.php out of my repos. Other developers may disagree but I try to avoid committing passwords wherever possible. One of the drawbacks to Git keeping track of every change to a codebase is that passwords that have been committed once can be recovered later (unless you purge it from the repo). When deploying to a new environment, I think it’s easy enough to cp wp-config-sample.php wp-config.php then edit your newly-created wp-config.php file in the editor of your choice. By keeping your config file out of the repo you also reduce the risk of another developer accidentally overwriting your local (or worse, production) configuration upon deployment.

What’s your workflow like?

This workflow seems to work pretty well for me. I’m able to work locally, push it up to a remote Git server (usually Github, Bitbucket, or Gitorious), then pull the latest version of the repo into the staging and/or production environments. I don’t need to make a copy of my uploads directory, worry about my configuration being overwritten, or worry about polluting the repo with any of my environment-specific configurations or system files.

What about you? How are you using Git in your WordPress workflow? I’m especially curious to see how other developers handle moving the database between environments!