Apr 08, 2013
Table of contents:
One of the legacy problems with WordPress is it does not offer an easy out of the box solution for using Git. This means that it is often the case that theme management is handled through FTP.
Using Git for deployment is far superior than FTP in just about every way. In this post I will show you why you should only ever deploy with Git, and how easy it is to set it up.
I’ve already covered why you should use Git in the past, so I will keep this to a brief summary.
Git is a version control system that sits discretely in the background of your project and monitors any changes you make. After you make a change to your code you can commit your changes to Git which makes a new entry in your project’s timeline. This gives you the ability to go back in time and resurrect your code as it was at a certain point in time.
Git is also invaluable when you are working as part of a team of developers or when you are working on a project that has many concurrent development features or versions.
One of the big advantages of using Git is when it comes to deployment. As you probably already know, using FTP for deployment is not very good. FTP requires you to drag and drop files into their correct folders on the server. This means if you need to update a website that has files that are changed in many different folders, it becomes quite difficult. You also face the risk that an unsuspecting user will load a page that breaks because you haven’t finished uploading all of the new files.
Git allows you to manage deployment from the command line. This means you can push a new update and all of the files that are changed are instantly updated at the same time.
It also means that should you push a new update that critically breaks your website, it is really easy to rollback to the previous version. This would be almost impossible using regular old FTP.
So hopefully you can see the many advantages of Git when it comes to deployment. Again, Git will improve your workflow in a number of different areas which you can read more about.
There are many different ways you can handle Git deployment using WordPress. Personally, I only use Git for theme deployment, rather than having it manage my entire WordPress installation. This is because I don’t trust open source plugins enough to compromise my deployment. For example say a plugin makes a change to a file on the live server. The next time I push a deployment my files will overwrite this change.
If you do want Git to manage your entire installation, that’s fine. This is a good set up because you can update plugins locally to ensure nothing breaks before it ever hits the live server.
So the overview of how my Git deployment works is:
Firstly I have my WordPress installation set up locally so I can develop themes and make changes without affecting the live site. Making changes to a live site is a really bad habit that you need to get out of. I have my Git repository set up in
/wp-content/themes/my-theme so only the changes to my theme get managed.
Next I have a bare repository set up on my server. I like to keep all my repositories under
/var/git, but you can keep them wherever you want really.
And finally, I have my live site WordPress installation under
/var/www/path-to-live-site as you typically would with any Linux set up.
So the workflow of making changes is:
Local changes Firstly we make local changes and commit them to Git
Push to the server Next we push the changes to the Git repository on the server
Automatically update When new commits are added to the Git repository, it will automatically update the live theme.
It’s that simple. Easy integration with Git and no more FTP.
Let’s set everything up.
So as I’ve outlined above, there are three main stages to setting up Git to work with WordPress:
So the first thing to do locally is simply create a new Git repository. I’m going to assume that you already have Git set up on your machine.
To create a new repository, go to the root of your theme and run:
$ cd wp-content/theme/my-theme $ git init
This will create a new repository.
Next we need to add all the current files to the repository.
// Shows all unstaged files $ git status // Adds all files to the current commit $ git add -A // Commits the files with a message $ git commit -m "Add all the things"
Now if you run
git status again, there should be nothing left to commit.
Next we need to create the server repository. SSH into your server and into the directory where you want to store your Git repositories.
All we have to do at this stage is to create a bare repository. Run the following command in your directory.
$ git init -bare
A bare repository is essentially the same as the local repository you just made but it doesn’t have a working tree. You should use bare repositories to push and pull from on a centralised server because it doesn’t have the complications of a working tree.
Now that we have a repository to push to on the server, we can add an origin to our local repository.
Go back to your local repository and run the following command, substituting your SSH login, server IP and path to the bare git repository you just made:
$ git remote add origin firstname.lastname@example.org:path/to/your/git
You should be required to enter your server password.
Origin is simply the main centralised repository. Even though all of your work originated from your local machine, the bare repository is still called the origin. This means that should you ever want to allow access to another developer, all they have to do is pull from the origin.
Next you can run the following command to push your code from your local machine to the server:
$ git push origin master
This is simply saying, push the master branch of the current repository to the origin.
Now if you have a look at the
git log of the server’s repository, you should see that your code has been pushed up. Because this is a bare repository without a working tree, your code won’t actually be in the repository.
If you look at your live installation directory, you will notice nothing has changed. In order to automatically update the live files we need to set up a post update hook. This is simply a job that will be run whenever the git repository is updated.
Go into your bare repository, then into the
$ cd hooks
If you list all of the files in this directory you will see a set of sample files that you can use to create your hook.
$ ls -l
To create a post-update hook, simply create a new file and copy the following:
// Create a new file $ sudo vim post-update // Copy this text #!/bin/sh export GIT_WORK_TREE=/path/to/you/live/files git checkout -f
This will checkout your files into the directory your have specified every time the repository is updated.
Now if you go back to your local code, make a change, commit the change and push it to the origin you will see your code magically update. You can now deploy changes to your live site without ever having to touch FTP again.
And there you have it, simple Git deployment using WordPress. There are many ways you extend this. For example, you could deploy to a development version or staging version depending on which branch that you push to the origin. This would allow you to test your changes on the server before you deploy the code to the live site.
Hopefully that was a nice and easy introduction to using Git with WordPress. You can of course use the same technique for deployment of any website. I promise you, once you get away from using FTP, you will never look back.