How I manage the WordPress theme with Git

Posted on September 30th, 2010

I thought it might help somebody the way I’m currently managing my WordPress theme. First of all, I have to say it would be better to have an actual WordPress installation in my localhost, so it would be easier trying out changes (on themes and plugins) before committing them. I’m just too lazy for that, so I’d rather have only one running installation of WordPress on my server and a moving git repository for the theme alone. So this is how I do:

1. I have a Github public repository to share my theme (not like anyone is interested anyway)
2. I have another private repository in my server to store all the changes of the theme and actually update it.
3. I have a local repository in my computer for the theme.
4. The theme is actually stored at my_server_root/my_wordpress_path/wp-content/themes/bernatfarrero/

Let’s start out creating the local repository in your local computer:


mkdir bftheme && cd bftheme
scp -r my_server_root/my_wordpress_path/wp-content/themes/bftheme .
git init #We initialize the local repository
git commit -a -m "Initial commit" # And we make the first commit

We’ve just made a local copy of our theme and we’ve set up a local Git repository. Now let’s synchronize it with our server’s repository. In my server I have a special directory for all my repositories called repo. So, now I have to login via ssh to my server and do the following:


cd my_server_root/repo #this is were I store my repositories
mkdir bftheme.git && cd bftheme.git
git init --bare
git config core.worktree my_server_root/my_wordpress_path/wp-content/themes/bftheme
git config core.bare false
git config receive.denycurrentbranch ignore
vim hooks/post-receive #Open this file with your favorite editor and write inside it:

#!/bin/sh
git checkout -f

#Save it and close it
chmod +x hooks/post-receive #Give it running permissions

The denycurrentbranch set to ignore (or warn) basically makes the server not complain for having uncommitted changes on the remote repository. Even so, as we only want it to mirror our local changes, we don’t care. We’ve set the post-receive hook so it resets our repository to the latest changes received by our last push. Now in our local computer, we have to tell our repository who will be the remote:


git remote add origin username@host.com:repo/bftheme.git
git push origin master

And that’s it. We’ve established the connection between our local repository and the actual changes made public in our blog. In order to deploy your changes just do:


git push

And you should see them right away. If you do not, there will be some problem with the paths, or make sure you don’t have any caching plugin (like Super Cache) activated at the moment. If you are like me and want to push every now and then the changes to Github, you can do (in your local computer):


git remote add public git@github.com:bernat/blog.bernatfarrero.git #In my case
git push public master

You can do that every once in a while. In case you don’t want to push all commits to Github because you are shy to show a zillion of irrellevant changes, what you can do is set the Github repository as origin and the other as, say, deploy. Every 10 commits or so, you can do (in your local computer):


git rebase -i master~10

pick A
pick B
pick C
pick D

replace all the pick by squash (except for the first one) and then give it a nice message name. This way you assemble one big commit with the changes of your last ten commits. Then, to push it to Github, you can do:

git push origin master #In case you set Github remote as origin

This way you will push a bigger and more controlled set of changes to Github and only after a while. In the meantime, to see your changes in your actual blog you would just go