Version control is one of the most important things you can add to your workflow, not matter what type of WordPress development work you do. It solves so many problems while making your life so much easier. Version control isn’t just the ultimate undo button, perfect for anyone who ever makes mistakes, it can be used as a backup and deployment tool. Beyond that, it creates a record of what was changed when, and makes collaboration easy.
The most popular–for good reason–version control system for WordPress development is Git. Earlier this year Andy Leverenz covered the basics of using Git for version control. If you’ve never used Git, I recommend reading that article to get a basic idea of what Git is and how it works. In this article I’ll cover using it with WordPress and some of the important decisions to make, such as where to host your version controlled code, what to place under version control and deployment strategies. I’ll also discuss Git GUI tools that make it easier to use, including one option that works from inside WordPress itself.
Should You Be Using Version Control?
For the most part if you’re doing anything beyond installing pre-built themes and plugins, I think the answer is yes. If you’re writing any code, even just CSS in a simple child theme, you should be using version control. It might not seem important at first, but once you’ve been asked to undo a change you made, go back to the way things were last week, you’ll appreciate having version control in place.
Where Git really shines is the ability to see each change individually. This is incredibly important when you need to undo one change without loosing everything else that you or your client likes that’s changed since.
Version control is especially important when working in teams. We’ve all been involved in nightmares where we’ve found oursleves working on the wrong version of a file. Even worse, have you ever made changes to part of your theme only to have the changes lost when someone else uploads a version of the file without your change in it to the server? Version control helps avoid these situations.
What To Version Control?
While in some cases you may want to add your entire possibly including WordPress itself under version control, but most of the time that’s not a great idea. Having your whole site under version control complicates updating plugins and WordPress, and can inflate the size of your Git repo for no reason.
Also, don’t forget that Git is only one of many version control systems for source code. There is also Mercurial, which is not very common in the WordPress ecosystem and Subversion. Subversion is used for managing WordPress core, as well as the WordPress.org plugin and theme repositories. Subversion is harder to use, less widely used for deployment tools and has fewer GUI tools, none of which are free and, in my opinion, very good.
WordPress is full of code that you never would edit. Most of the time that includes your plugins and WordPress itself. There are better tools for managing other people’s code, such as WordPress or Composer.
A good rule of thumb is that you should only have the code that you’re writing under version control. For a lot of people this means their child theme. You are using a child theme, not modifying your theme directly, right? If all of your custom code is in your child theme, then you can let WordPress manage everything else, while the child theme is version controlled.
One reason to put your entire site under Git version control is that it allows you to use Git as a deployment tool. Some people use git to deploy their site to their server. This can be accomplished by adding the live server as a Git remote and pushing changes directly to it, or pulling changes from your Git host to the live server. There are also automated deployment tools, such as Beanstalk that pull from a Git repository.
Should You Use A GUI Tool?
Git can be operated entirely from the command line, but doing so is not necessary. There are excellent GUI tools available. Not only do Git GUI tools make it easier to use Git, they help you visualize the state of your Git tree and merges. More importantly they help you manage setting up remotes, pushing and pulling from theme, as well as handling merge conflicts.
There are several free GUI tools to consider, including GitHub’s app, SourceTree, and Git Tower and the open source Git Cola. GithHub’s app is an excellent for Git beginners as it’s the simplest to use, but it’s also is the least fully-featured. Personally I use SourceTree as, in my opinion, it has the best features and Git tree visualization. More importantly it works great with both GitHub and BitBucket, the two Git hosts I use. Also, it’s free.
Integrating with the Git host you use is probably the most important thing to look for in a Git GUI tool. One of the most difficult things to set up manually for Git is SSH keys to allow you to push to any repository or pull from any private repository that you should have access to. Using a Git GUI tool that handles authentication for you is a wonderful way to make your life easier.
What Git Host Should You Use?
While you don’t technically need to have your a remote server hosting your Git repository, it’s almost always necessary. Pushing to a Git host that is neither on your own computer or server does two important things. Those are creating a backup of your code and making it easier for multiple people to contribute to your version controlled code.
There are a lot of options for Git hosting out there, including your own server, if your hosting provider allows for it. While GitHub and BitBucket are the most popular in the WordPress world, GitLab and Gitorious are other options to consider. All of them offer a different mix of additional services beyond just GitHosting including issue trackers and wikis as well as an easy interface for managing who has read, write and admin access to the repository.
Since GitHub is the most popular Git hosting network, if you are developing a plugin or theme for others to use, you really should have it on GitHub so other people can contribute code, report issues, or try out your latest changes before they are officially released on WordPress.org. If you’re using Git for code that has a single purpose, such as a child theme for a specific site, GitHub still works, but if you want to make your code private you will need a paid plan.
On the other hand, BitBucket, which is not a great choice for public projects, offers unlimited free private repositories. That is perfect when your repository contains sensitive information, such as a wp-config.php file, proprietary code or premium GPL-licensed themes or plugins you don’t want to distribute for free out of respect for the authors.
Another reason why you might want to choose BitBucket, is that it has excellent integration with other tools by the same company. These tools include Jira, Confluence and HipChat, the popular chat tool for group software development.
What About The Database?
Nothing I’ve discussed so far covers WordPress’ database. Version control for databases is a totally different topic and a very serious technical challenge. Also, since WordPress has an excellent post revisions feature–ie version control for post content–you probably don’t need separate version control for your database. This is especially true because it is so hard to do right.
That said, there is one good WordPress solution for this, and that is the plugin Revisr. Revisr is essentially a Git GUI tool inside of the WordPress admin. It’s got a lot of great features and I recommend you check it out and consider using it as part of your Git workflow.
One thing that Revisr does that is really special and unique, is every time you make a commit, it creates a backup of your database and adds it to the commit. This means that when you roll back to a previous commit, you’ll not only be rolling back your code, but also have the option to roll back the database to where you were then. That might not be something you always want, but there are times where it could be a life saver.
What Else?
Git, and version control are huge topics. I’d strongly encourage you not just to use Git, but to make a plan for how you’re going to use Git and stick with it. If you’re working in a team, having a plan and a commitment to sticking to it is even more important.
One of the best part about Git is that it allows you to experiment knowing that you can easily discard your changes without committing them or to revert commits later. More importantly, version control systems make it possible for people to work together from all over the world to effortlessly contribute to the same projects. For me, that’s one of the greatest parts about being a WordPress developer.
Article thumbnail image by Jane Kelly / shutterstock.com
Having used WP Engine’s staging environment, I’d really like to build a similar system using Git for version control.
Got some great tips from this post so thanks, Josh!
Is there any particular reason to use Git, versus using a dev/staging site with WordPress?
I have always found it easy to set up a dev site, on my hosting account, and work on the WordPress site there. Once it is ready to go live, I create the live site’s hosting account, clone the dev site, and move it to the live site. After that, I can continue to use the dev site, for changes or testing updates, before cloning the site over to the live site.
I use a plugin, called WP Clone, for the copying/moving of sites. It is very easy. Basically, you click the Clone Site button, it copies your entire site (including database, unless you tell it not to), and gives you a URL to paste into the WP Clone section of the WordPress install you want to move it to. Then, just click the Restore button on the new site. Viola! It’s done. Often, it will ask you to re-save Permalink structure but, it provides the link to that section, and all you have to do is click the Save button.
Good article on getting people to see the value of version control for WordPress and some tactical pointers. I do have to take issue with your comments about Subversion though.
>Subversion is harder to use
Sorry, but this not true. I appreciate that you prefer git, but you can use Subversion with just 2 commands – update & commit. Not so difficult.
>less widely used for deployment tools
Once again, not true. There is Subversion support for almost every deployment tool that is not a git-only solution.
>has fewer GUI tools, none of which are free and, in my opinion, very good.
This depends on what platform you develop on. Most IDE’s have Subversion either built in or as a plugin. TortoiseSVN on Windows is the de facto GUI client (and free).
@Wayne – In some ways Subversion is much easier to use, in other ways it’s almost impossible. The fact that it’s not distributed can create lots of problems and branching is a nightmare. It’s a good tool for certain use cases and Git for others, as is Mercurial. I tend to like Mercurial better than Git, but Git is the most popular tool at the moment and so being proficient in it makes sense to me.
Another informative post. Learn lots of new things from the post. Thanks for the awesome share.
Quite a niche topic.. but very interesting! never heard of Git before, thanks!
Great post, I didn’t know about Revisr, which completes my WordPress Git/Capistrano development/deployment workflow!
A full strategy for developing WordPress using Git was described by Mark Jaquith (lead developer at Automattic) a couple of years ago. It keeps WordPress in a subdirectory (ie Git submodule) so that you can keep your plugin and content files separate from core WordPress. The full strategy is described here:
http://markjaquith.wordpress.com/2012/05/26/wordpress-skeleton/
He has also created a Git repository for you to start from on GitHub at:
https://github.com/markjaquith/WordPress-Skeleton
I have just completed implementing the full workflow he described ie develop on laptop, use Capistrano V3 to deploy to a staging server, then to a production server.
I intend to write it up soon as it was a struggle to pull all the threads together, but it’s well worth it to end up with a professional setup.
I would recommend VersionPress http://blog.versionpress.net/2015/05/versionpress-1-0-walkthrough/ for the database versioning.
@Josh – thanks for the post. I especially like the Revisr recommendation. I’ve been pulling my hair out trying to figure out how to get the database under version control!
@Henry – please post back here with the URL to your write-up when you complete it. I’d very much like to hear your experience.
R
Great post, Josh.
I currently take the approach of putting the entire site (with a handful of exceptions added to .gitignore – see below) under version control. I like the ability to update WordPress and all its plugins locally, test it out first, and then deploy them to my production server with “git pull” once I’m ready. Granted, I lose the ability to update the production server via the WordPress dashboard, but so far this approach has worked well for me.
Here’s a portion of my .gitignore:
local-config.php
wp-content/gallery/
wp-content/uploads/
wp-content/backup/
wp-content/cache/
wp-content/upgrade/
wp-snapshots/
wp-content/debug.log
wp-content/.htaccess
wp-content/advanced-cache.php
wp-content/wp-cache-config.php
wp-content/plugins/wordfence/tmp/configCache.php
What part of your WordPress install do you guys put under version control. I’m only putting my active themes en custom plugins in there. Any other thoughts or useful gitignore suggestions?
I mostly work with plugins and themes, so I usually don’t setup whole WordPress website as a git repo. Instead of that, I setup each repo for each plugin and theme. It keep me sync everything between computers with fast download/upload.
I add everything from wp-content down. So that’s basically just the plugins and themes folders.
As far as gitignore, I usually start with the following:
uploads/*
cache/*
upgrade/*
.DS_Store
._*
*.LCK
error_log*
Custom Post Types are another huge thing to put in there. Of course if you’re working with a child theme they most likely reside in your functions.php file so you may already be running those files through your Git. I’ve pushed some 3rd party plugins off to Git as well when I’ve modified them.