The Easiest Way to Use Git with WordPress

Are you a WordPress developer getting your feet wet with Git and version control? Do you want to want to "really" learn Git, level up your WP dev workflow, and not settle for visual applications that do things for you? This page is the quickest ramp up to Git you can get - guaranteed. Okay, we can’t really guarantee this type of thing. But we promise it’ll be pretty fast.

We’re the makers of Pantheon, a WordPress-optimized hosting platform built for developers, which has version control built in, making it much easier to ramp up and start working like the pros. There are three ways we make Git easier for WP developers:

A dashboard: Lets you view your latest changes, and perform simple operations like staging a file and pushing a commit to your server, using a friendly UI.


Dual access with Git/SFTP: Pantheon lets you work like the pros using Git commands in the console. But you can easily switch to SFTP mode and upload files with a regular FTP client. Even if you upload with SFTP, the files are checked into version control behind the scenes and become part of your version history!

Pre-configured dev/test/live environments: To really do version control, you want to be able to push your changes from a local environment, to a development server, then to a testing environment, and finally to production. It’s difficult to set up all these environments on your own, so Pantheon does it for you. With one click of a button you can move changes to a realistic testing server, and if all looks good, push to production.


In This Page: Git for WordPress the Easy Way

We’ll go through a 3-step tutorial helping you ease into Git with WordPress, on the Pantheon platform:

  1. We’ll push site changes to Pantheon using familiar SFTP, not Git, to show you how easy it is to commit new changes and take them through a full development-test-live cycle.
  2. Now using Git on a local development environment, we’ll push a change and see how Pantheon’s tools come to your assistance.
  3. Finally we’ll do The Cool Thing you’ve been waiting for - revert back to a previous commit to restore a previous version of your code.

Note: In this page we’ll show you the essentials but we won’t explain all the possibilities and commands in Git. We’ll refer to other great resources that do that.


1. Pushing Site Changes to Source Control - without Git Yet

In this section we’ll show how to add a file to your site, commit it to version control and push it through dev, test and live environments - without knowing Git yet!

Why is it important? The first step of using version control like Git is to learn how to “stage” your files in the version control sandbox, and then “commit” them locally, making them part of your version history. You then “push” the files to a remote server to make them available to others or deploy them to a real server.

Let’s get started. Create your free Pantheon account, click Create new site, give it a name and click Create Site. Select the Start from Scratch radio button and click Install WordPress below. This will take a minute as we spin up the containers for your new WordPress site.

When your site is ready, click Visit your Pantheon Dashboard:

Every development environment has a toggle to switch between SFTP and Git modes. By default you’ll be in SFTP mode, we’ll stay there for now.

Create Your Dev, Test and Live Environments

Pantheon for WordPress comes with three built-in environments - Dev, Test and Live. To quickly create your Dev Environment, click Visit Development Site at the top. Quickly go through the WordPress installation process to set up your sample dev site, and log in with the password you defined.

Now click the Test tab at the top. You should see this:

Click Create Test Environment - and your development WordPress instance is deployed to a new container with a realistic server configuration for testing.

Now Click Live at the top and Create Live Environment - the test WordPress instance is deployed to a production container which can be used as a live site.

Let’s Push a File through Dev, Test, Live

First we’ll need to create a local copy of your WordPress site. To ease you into things, we’ll start using a regular SFTP client.

Click Connection Info to get your connection credentials and a link to connect directly with your preferred client such as FileZilla (if the link doesn’t work, open a new connection in the SFTP client and copy in the credentials). Note: When you set up your SFTP client, remember that SFTP is the protocol and you need to connect to your environment using port 2222.

Your website is in the code directory. Download this directory to a local folder and we can get started.

Create a New File and Commit to Version Control

Now let’s go to the new folder and create a regular text file named new_file.txt. In it type the text “A change to my site”.

Upload this file using the SFTP client to the root of the code directory. This performs a git add command behind the scenes - the file is now registered by git and ready to commit.

Go to your dashboard, and you’ll see this message:

Click the message and you’ll see the content of the change - the name of your new file and even its contents.

Write a helpful commit message to go with your changes - “adding new test file”. Commit messages are extremely important when using version control, because afterwards these messages are the only way for you and other developers to know what exactly you changed when you modified your code.

Hit Commit - behind the scenes this does a git commit, which takes the file you just added and creates a new version of your code containing this change. Currently the change is only on your development server.

You’ll now see your file in the Commit Log below - this is just a nice display of the git log command.

Also - click View Development Site. Your new WordPress site opens. Immediately after the root URL, type /new_file.txt. You should see your file.

Push to Testing and Production Sites

Click the Testing tab at the top. You should see the following:

Note the checkbox - this allows you to perform a realistic test by pushing the code from your dev environment, but taking files and database from your live site. So the test environment will have an exact copy of your live site, with the very latest content, only with the new code substituted for the old. Cool huh?

Click Copy Content from Live and Deploy Code from Development and your new file will be deployed to the testing environment, a WordPress instance with realistic server configuration, caching, etc.

In the background, this performs a git push command. When you deploy to a test or live environment, the Pantheon platform creates git tags, which capture the current state of the "master" branch.

You will now see your file under the Deploy Log below. Click on Visit Test Site at the top, and add /new_file.txt to the root URL. You should see your file - now on the testing server.

It’s show time - let’s push to production!

Go to the Live tab, and click Deploy Code from Testing. Again, this performs a git push command to the live environment. Now click Visit Live Site and again, add the path to your file in the URL. You’ll see your file as part of the production WordPress environment.

You just added a file to your project, committed it to a dev server, reviewed it on a realistic test environment, and promoted it to production! All steps have been recorded in version control.


2. Pushing Site Changes with Git - Much Easier with Pantheon

In this section we’ll show how to add the same file, but this time using Git commands in your console, assisted by Pantheon’s features: dashboard, dev/test/live workflow, realistic test environment.

Why is it important? We’ve already seen the basics of staging a new file, committing and pushing it - but we did this with FTP and the Pantheon UI. Let’s see how to do the same thing in the console with “real” Git commands. After all we want to work like the pros.

Install Git

Select your operating system and the download will automatically begin:

Mac OS



Clone Your Site Codebase

The first step is to get a git clone of your code from Pantheon to your local computer.

Step 1: Go to Your Site Dashboard

Log in to Pantheon and load the Dashboard for the site you want to work on.

Step 2: Copy the Git Clone Command

At the top of the development panel, look for the git clone command and copy and paste it in your terminal. It will look something like this.

Step 3: Run Git Clone

On your local environment, go to where you want the code to reside. Git will create a directory as part of the clone, so you don't need to create one. Run the command you copied in step 2:

git clone ssh:// my-site

If everything worked correctly you will see git fetching the data.

Make a Change

Let’s make a change to the file we added in step 1 above. Open your text file and change its contents to "A change to my site from git on the command line!"

You will now need to tell git about the file, or else git will not track the file.

git add _path_to_file_

To find out if you have any files in your local clone that git isn't yet tracking, run:

git status

Any pending changes and files to be added will be listed like this:

You can then cut and paste the paths to these files when using git add .

Push Changes to Pantheon

Sending code to Pantheon is a two step process with git. First, you need to commit the files locally. Then you need to "push" them to the Pantheon cloud.

Step 1: Commit the Files Locally

In order to tell git the files are ready, you need to commit them. As mentioned previously, you must include a meaningful commit message to help others understand your changes.

git commit -am "Changed my text file from git!"

If the commit worked you will see something like this.

There is a handy list of Git commands (along with a lot of other documentation) on GitHub.

Step 2: Send the Changes to Pantheon

You have committed the file locally, but you still need to send the changes to Pantheon. To do this, use the push command:

git push origin master

This executes a push to the origin location, which is Pantheon since that's where you cloned the code from, on the branch "master", which is what your Dev environment tracks.

If everything worked, you will see something like this.

Step 3: View the Changes on Pantheon

When the push command completes, Pantheon instantly deploys the changes to your development server.

Go back to your site's Dev tab in Pantheon, click the URL under Development site, and browse to your changes.


3. The Cool Thing - Reverting to Previous Commit


In this section we’ll show how to go back to a previous version of your codebase and push it to your production site, effectively “rolling back” your site to a previous version.

Why is it important? We all make mistakes. One of the cool things about version control is the ability to revert to a previous version of your codebase if you find a problem with the current version. 

The following command will reverse the last commit in your version control history, and deploy it to your dev server on Pantheon. The current version will still be saved in your version control, and you’ll be able to go back to it if you want.

git revert HEAD --no-edit
git push origin master

When the push command completes, Pantheon instantly deploys the changes to your development server.

View your site's Dev tab in Pantheon, click the URL under "Development site", and browse to your changes. You should see that the latest commit has been rolled back. Specifically, your second text file has been removed and you should be back to your original text file contents, "A change to my site".

You can now deploy this change to the test and live server, to roll back your production site to the previous working version.

Of course, Git allows you to roll back to any previous commit, not just the last one. To do that, run git log --pretty=oneline -10 to view a hash code of previous commits. Copy paste the hash code of the commit you want to revert to, and then run git revert hash_code --no-edit .

Additional Resources on Git

For further learning, we recommend the following resources:



Tips from Gilbert Pellegrom of Delicious Brains:

Always install WordPress as a subfolder using either Git submodules or Composer. That way you can include WordPress as a dependency in your project without committing WordPress source code to your Git repo.

Tips from Priit Liivak, Head of Engineering at Nortal - the importance of version control and automation:

  • Version control everything. Developing WordPress shouldn’t be any different than creating a custom web application from scratch. As many sources as possible should be under version control.
  • Automate your deployment process. Manually updating a theme or template is tedious and error-prone. These activities should be scripted even in a development environment. This kind of automation requires a single repository to share code and resources.

Tips from Pradeep Singh of WPism - tips for Git beginners:

  • After reading the article, I can see that Pantheon makes it easy to visualise and understand version control by integrating the process within its dashboard. This can can help beginning developers understand how version control and Git actually work and to speed up their learning.
  • Using Git can be an essential skill for those who want to write code, work in a group, and contribute to open source software like WordPress.
  • While there are plenty of GUI tools out there, which are continuously improving to accommodate more features, it’s still necessary to use the command line to get the full Git experience. I highly recommend that beginners spend some time learning the command line and getting comfortable with Git commands. This will also be beneficial in the long run and will speed up overall development.

Tips from Shannon Kleiner of EXERTUS - correct branch management and backup processes:

  • Consider appointing one individual repo/branch manager. This will streamline changes and help prevent clashes and inappropriate merges/overwrites.
  • Git is no excuse for a lazy backup procedure! Always maintain a regular, consistent backup process for all files and database information—be it through your host's provided backup solution or your own.

Tips from Andy Brudtkuhl of - using .gitignore file:

  • Using a .gitignore file for WordPress is essential for keeping your repository clean from uploads, cache data, and configuration files. The contents of your WordPress .gitignore will vary based on your version control strategy. Some devs will keep the entire site in their repo - including WordPress core and plugins. Others will only keep their custom theme and plugin code in version control. There is no right answer for this. It can depend on the environment or project.
  • However there are a couple things you always want to ignore:
    • First off, your wp-config.php file should be ignored since it contains sensitive information about your database and is generally environmentally specific anyway.
    • Second, you will almost always want to ignore the /wp-content/uploads folder. The media library and associated assets should be treated as content or data not kept in version control. Also - it makes a repo take up storage space quick. Stick to a tool to sync media between environments.

Tips from Mariana Malashniak of Letzgro - database synchronization:

  • WordPress is a very powerful system, however, developing a website with a very small team can be challenging.
  • While versioning the code is easy, WordPress stores a huge amount of information in the database including revisions, custom fields, and so on, etc., so a solution is needed for database synchronization.
  • At Letzgro, we use a remote server for local development and local servers for staging, production, and so on, but this is only a partial solution: There are still issues with the performance of local development environments. If you are already in production, some migration scripts should be written to merge databases.

Tips from Danila Sentyabov of - atomizing the database:

  • The most important thing for making WordPress and Git play well with each other is bundling the database state with the files' state.
  • In my opinion, properly atomizing the database into a bunch of small text files on which Git tools could operate efficiently is the key.

Tips from Kazik Pietruszewski of - dependency management:

  • After reading the post, I can see that Pantheon has made an effort to simplify working with WordPress and Git, even for beginners.
  • There is no need to keep your dependencies under version control, consider using Composer to install plugins and WordPress itself.
  • When starting a new WordPress project, consider building it on top of a Bedrock WordPress project boilerplate. You can combine it with other tools from the Roots family to take advantage of an improved WordPress project layout and dependency management with Composer and Bower. You can rely on many best practices baked into these open-source solutions.

Tips from Peter Suhm of WP Pusher - Git and overhead:

  • Don’t think of adapting Git as overhead. Version control is just a part of being a developer. Real overhead is:
    • Having to manually sort out different features, releases and bug fixes
    • Not being able to work as a team
    • Not having backups and history of your code changes
    • Having to deploy manually
  • NOT using Git creates extra overhead.

Tips from Steve Grunwell of 10up - Perform proxy uploads from production into dev/test environments:

  • One of the easiest things you can do to simplify your WordPress development workflow is to perform proxy uploads from production into your dev/test environments. Remember: source control – in this case, Git – is meant for tracking changes to your code, not your content. With just a few lines of server configuration, you can seamlessly load any assets that don’t exist in your environment from production.
  • For Apache, we’ll use the rewrite module (mod_rewrite) to first check if an upload exists locally and, if not, will rewrite the URL to point to the production version. This code can be added to your Virtual Host or your site’s Htaccess file, simply replace $PRODUCTION with your production URL:
  • <IfModule mod_rewrite.c> RewriteEngine on # Proxy uploads from production. RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !-f RewriteRule wp-content/uploads/(.*) http://$PRODUCTION/wp-content/uploads/$1 [NC,L] </IfModule>
  • If you’re running Nginx, the comparable code looks something like this:
  • # Proxy missing media to production: location ~ /wp-content/uploads/*$ { try_files $uri $uri/ @production; } location @production { resolver; proxy_pass http://$PRODUCTION/wp-content/uploads/$uri; }
  • In either case, the web server will take a request for uploads and, if the file doesn’t exist in the current environment, will proxy the request to the production server. Now you’re able to spin up new environments with ease, no longer having to copy uploads from one environment to the next nor fighting broken images in your non-production setups!

Ken Young of Uncanny Owl - choosing the right IDE:

  • Choose an IDE that supports multiple projects and integrates with both Git and FTP/SFTP.
  • This makes it easy to switch between projects and push to or pull from any destination using a single interface.