How to manage WordPress using Git

Last week I published an article about why it's a very bad idea to use FTP to manage our site. Although the topic is very general and not only applies to WordPress, this time I want to explain a little more about the process I personally use to combine WordPress with Git.

#What is Git?

If this is your first question, my young grasshopper, you have a long way to go. But don't worry, we all do.

To start, Git is a file versioning system, something similar to SVN, but generally more appreciated. Git allows us to save versions in time of each file we modify, this way we can easily go back to a previous version, or have a record of exactly what has changed, when it changed, and who changed it.

#Why use Git?

As I mentioned before, Git saves versions of each file on our site so we can go back to any of them easily.

Have you ever made a modification to a file, and all you got was a white screen? With Git, you could easily go back to a previous version of your site, to be able to find the problem without affecting your visitors.

Git is also very useful when we are working in a large team, or when many people can touch the code, as it saves a history of who, and when each thing was done. And many people can work on the same site at the same time without stepping on each other.

Convinced?

#How to use Git on our site?

We are almost at the important part, now that we know what it is, and what we need it for, let's see some of the most common ways we can use Git.

As a file versioning only

If we only need to have a history of changes on our site, and we don't need anything very complex, we can only create a repository, either on Gtihub, Gitlab, or Bitbucket.

Having our repository, we can add or modify anything on our site in a completely different version of files than what we have in production, this way we can keep them in the cloud without the danger of our production files being modified. We can also share our code with other members of our team, who can continue making modifications in their own versions.

As a deployment tool

One of the biggest advantages I see in using Git + WordPress is, in addition to file versioning. The possibility of moving our deployment flow to Git (to finally forget about FTP). These methods are a bit more advanced, but without a doubt, they make our existence much easier once they have been mastered.

The main idea is, having a copy of the repository on your development machine, and having a copy of the repository on the server. The recommended is, having in the repository only things we don't worry about being overwritten by an update. Such as:

• Our custom themes
• Our custom plugins

Therefore, most of the time, the repository will be made up of our wp-content folder. In the case that we have more plugins, made by other people or that are available in the official WordPress repository, it is recommended to ignore them in the repository, and manage them using Composer (which I will talk about in an article in the future).

Let's say we have already created our repository on Github, and we have added the contents of our wp-content folder to it, then we would have a repository more or less like this:

1git@github.com:user/site.git
2

Once we have our repository, we can now worry about synchronizing it with our server.

Deployment via SSH

As I mentioned in my last article, SSH is much more secure than FTP, and if we need to enter our server to move files or make configurations, it is also much more recommended.

To start, we need to connect to our server via SSH (it can vary depending on your hosting company, make sure you have access).

Let's say our repository is made up of the wp-content folder, and that it looks like this:

1- site
2--	.gitignore
3--	themes
4---		our-theme
5----		style.css
6--	plugins
7---		our-plugin
8----		our-plugin.php
9

View Gist on GitHub

To be able to replace our default folder with our new repository, we need to enter the server and create a copy of the repository:

1# Assuming that our wp-content folder is in /public_html/wp-content
2$ ssh user@domain.com
3$ cd /public_html
4$ mv wp-content wp-content.bk # Create a backup of the current wp-content folder in case we need it in the future
5$ git clone git@github.com:user/site.git wp-content # Create a copy of the repository in a folder called wp-content
6

View Gist on GitHub

And that's it! Now we have our local repository in sync with our repository on the server, and we can share files between them very easily.

I recommend having at least three branches in the repository:

• master, which we will use as production, everything here is the final version of the site and must be 100% tested before it arrives. It also serves as the base of our “feature” branches
• staging, which will be the test version of our site, a “beta” version so to speak, once it has been proven that the new functionality works here, we can send it to master
• feature/* Our “feature” branches are work in progress, they are not ready to see production and should only be merged into master once it has been 100% proven to work in staging. Once they have been merged into master, they will be deleted from the repository

The development process is quite simple once you master it, let's say we have created a feature/slideshow and we are ready to test it in staging, then we would do something like this:

1# Assuming that the work has been completed
2
3$ git checkout master
4$ git pull origin master # Make sure we have the latest version
5$ git checkout -b feature/slideshow # Move to a new branch so as not to modify production
6
7# Start and end of work
8
9$ git add -A
10$ git commit -m "Implementing image carousel" # Save a version of these files with the new modifications
11$ git push origin feature/slideshow # Send this new version to the remote repository (on Github)
12$ git checkout staging # Move to the staging version
13$ git pull origin staging # Make sure we have the latest version
14$ git merge --no-ff feature/slideshow # Merge our version with the carousel to staging to be able to test it
15$ git push origin staging # Send the new version of staging to the remote repository (on Github)
16

View Gist on GitHub

Now we have our new functionality in the repository, but we still need a place to test it, right?

For this, I recommend having a new test environment on the server (something like staging.site.com). With a completely different WordPress installation, its own database, etc. In which we will repeat the same steps we did before to create a copy of the repository on the server, with two differences:

1. We will create the copy of the repository within the folder of our test site (example: /staging.site.com/public_html) instead of /public_html)
2. The base of this repository will be a branch called staging instead of master, so we make sure to test things in the right place.

To make our deploy and test in staging, we move to the folder where we have the copy of the repository (wp-content), and do the following:

1$ ssh user@domain.com # Enter the server
2$ cd /staging.site.com/public_html/wp-content # Make sure we are in the test site
3$ git checkout staging # Make sure we are in the staging branch
4$ git merge --no-ff feature/slideshow # Merge our new work into our staging branch
5

View Gist on GitHub

And that's it, now if we enter staging.site.com we will see the most recent version of our staging branch, which now has the changes made in feature/slideshow. So, once we have tested the test site (we have not touched production yet) and we are sure that it will work correctly in production, we can merge our new changes:

1$ git checkout master # Make sure we have the latest version of master
2$ git merge --no-ff feature/slideshow # Merge our new functionality into master
3$ git push origin master # Send the latest version to the repository (on Github)
4

View Gist on GitHub

Now that we have the latest version in the Github repository, we have made sure that everything works as we want, and we are ready for deployment to production. We can enter our server and download the latest changes to production:

1$ ssh usuario@sitio.com
2$ cd /public_html # Make sure we are in production
3$ git checkout master
4$ git pull origin master # Download the latest changes from the repository
5

View Gist on GitHub

And that's it! We have the latest version of our site in production, now we can do a final test just to confirm and our deployment is complete.

What if something went wrong?

In the unlikely event that we did not test the new functionality as we should and for some reason our site in production went down, there is no reason to panic, the priority now is to return production to a previous version that did work, which in this case, would be just before we joined the carousel to production, that is, just one version before, we enter the terminal and do something like this:

1$ ssh user@domain.com
2$ cd /public_html # Make sure we are in production
3$ git checkout master
4$ git revert HEAD # Revert the last commit, return to a previous version
5

View Gist on GitHub

This will return exactly one version back, which in this case, just before our carousel, raising our site in production and giving us time to find and fix the error locally without production being affected again.

#Next steps

This turned out to be a larger article than I expected, but this is not the ideal flow that inspired this article, in the next one, I will explain how to automate the process in staging to reduce the number of times we enter the server, and explain what tools can make this process even easier.