DEV Community

Cover image for Pushing WordPress Theme Updates With Git

Pushing WordPress Theme Updates With Git

jackharner profile image Jack Harner πŸš€ Originally published at ・Updated on ・2 min read

Do you frequently update WordPress themes? It's kind of a pain in the ass, right? Typically has to be done manually through FTP or uploading a new zip through the backend.

Well, today I'm going to show you how to update your site with just:

$ git push live

Sounds to good to be true? It's not. Check it out:


1) SSH Access to your web server
2) Git installed on your local machine and on your web server

This setup works best for one off customs themes (like the one on and not for themes produced to be distributed.

Create Your Repo Locally

First things first, create a folder for your project and enter it:

$ mkdir git-test && cd git-test

then initialize the repo:

$ git init

Alternatively, you can just clone my Blank2 - Blank WordPress Theme repo to get started:

$ git clone git-test

Create A Bare Repo On The Remote Server

A bare repo is a directory containing the working tree of your git project, just without storing all the files. It's essentially just a directory of all the files noramlly in your .git directory.

SSH into your server:

$ ssh <user>@<server>:<sshPort>

Create a folder for the bare repo and enter it:

<user>@<server> $ mkdir git-test.git && cd git-test.git

Remember where on the server you created this directory, you'll need that later (Doing it in your home directory works perfectly fine).

Initialize the bare repo:

<user>@<server> $ git init --bare

Hook It Up

Your shiny new bare git repo has a directory hooks and in it are a bunch of .sample files. We want to do something after the repo receives new data, so create a new file called post-receive (no extension) and add the following to it:

GIT_WORK_TREE=<pathToWordPressInstall>/wp-content/themes/git-test git checkout -f

What this will do is, any time you push to this git repo, set the working tree for the repo to the theme folder in your WordPress install and then force checkout the files.

Back Down From The "Cloud"

Now logout of your remote server. It's time to add the new repo as a remote for your local one.

Make sure you're in your project's folder:

$ git remote add live ssh://<server>/home/<user>/git-test.git

and that's it! All you need to do to update your live theme now is add some files, commit them like normal and then run:

$ git push live

Being able to Update WordPress sites quickly allows for quicker bug fixes and less time spent wrangling files. Combine this idea with a taskrunner like Gulp and you'll be flying through updates.

Let me know if you use this method or if you have any other ways to manage WordPress Themes!

More Of My Writing

Discussion (11)

Editor guide
mlichwa profile image
Michal Lichwa

Great article! I use similar setup for all web projects (not only WP themes) I have. It is somehow annoying that there are so many great dev tools to automate our workflows yet Wordpress devs usually push their code via FTP. At least that's just my experience at places I worked for.

jackharner profile image
Jack Harner πŸš€ Author

For the longest time I was in the boat of "just zip it and upload it through the Admin Panel" until I started working with the customizer. Since those options are theme specific and when you upload a new zip it treats it as a whole new theme. All of the customizer options would be lost. This way's so much more efficient.

mlichwa profile image
Michal Lichwa

I had a similar approach and it wasn't great. I really wish there were better (easier) and more standarized tools to develop for Wordpress and Wordpress plugins.

Thread Thread
jackharner profile image
Jack Harner πŸš€ Author

I've definitely started looking in to using Docker for WordPress. It saves a lot of time in the initial install and running of the sites.

Thread Thread
mlichwa profile image
Michal Lichwa

Interesting. I didn't think of Docker so thanks for the tip. I will give it a try!

jnschrag profile image
Jacque Schrag

Thanks for sharing! My work uses WPEngine for our hosting and their service includes a git functionality. We set up a TravisCI script that runs when new code is merged into our master branch that then deploys our theme files to the staging version of our site so we can review it before we deploy our staging site to production. It's so much better than dealing with the hassle of FTP.

lewiscowles1986 profile image
Lewis Cowles

How are you handling dependencies in such a scenario, and what about test, staging, production pipeline? Are you only currently hosting on single-vps or shared hosting?

jackharner profile image
Jack Harner πŸš€ Author

Dependencies on the stuff that I've worked on so far are pretty limited. At most it's things like jQuery and maybe a slider, but then I just add those js files to the theme and use Gulp to concat/minify.

As far as test/staging/production it's mostly been:

  • test locally
  • push it up
  • fix bugs
  • repeat

I have started looking into using docker and WordMove as a way to have multiple copies of the same full wordpress install on multiple machines, but haven't fully implemented it into my workflow yet.

Currently, this has all been personal projects and a few freelance clients, but most of my sites are running of DigitalOcen droplets.

Obviously there are some steps I'd need to add to my workflow for any kind of enterprise work, so I'm open to suggestions if you have them.

lewiscowles1986 profile image
Lewis Cowles

Hey Jack,

I suppose it's best to start from, how are clients approving changes if it goes from local-dev to live?

I've worked in the way you've described before, so I know the stress and pain it can cause for me, and for clients.

I wouldn't call backups or deploys an enterprise pattern as much as a recognition of value.

You could start by enabling droplet backups, learning wp-cli for exporting the database, plugin & theme installs, experimenting in VM's.

I'm not seeing lots of use-case for WordPress in Docker containers outside of testing. It was different in the initial PHP7 launch, but it is the only actively supported release now (, but certainly having a repeatable Vagrant VM can be of use locally to experiment with adding caching or shared state (multi-server or caching or both).

Once that is done you could experiment with child-themes, and multi-site. That can provide a single login which lets you have mutliple sites with mostly shared features, the option to diverge in a branching pattern, and the ability to interact with and gain client approval on changes.

Small things like storing nginx configs as code in repo's can help repeat-ability and consistency.

To upload themes you can ensure the branch name is included so {branch}-{theme}.zip see for an example of using git tag shows how to get active git branch instead.

You could maintain branches for staging or use feature branches to facilitate, run webpack or gulp before creating an archive, push that to the right place using a tool like scp (digitalocean supports scp & ssh) and wp-cli install theme from zip

There is a whole lot of room to improve. Hopefully this helps some.

rahuldhangar profile image
Rahul Dhangar

Super awesome Jack! Its fun to read this post and I will surely try it up soon!

polyakovkakatya profile image

Thanks for sharing! I'm quite new in Git so it is helpful info.