Sign up for free

or sign up with

Thanks for teaming up with Buddy

Check your inbox and click the verification link to let your code flow.

Git, Continuous Deployments and Your WordPress Themes

This entry-level guide will help you introduce Git and continuous deployments to your WordPress themes development. If you are already familiar with Git, skip the first part and move on to the continuous deployment section.

Objectives of this Guide

With this guide you’ll be able to:

  • Set up your WordPress themes development workflow with Git and best practices in place
  • Design your first delivery pipeline for continuous deployments of your WordPress themes
  • Employ industry standards and best practices for your new development strategy

Why should you care about Git?

If you haven’t used Git yet, you may wonder why should you go for it. Here is a bunch of reasons.

Advantages of the Git distributed Version Control System

  • Keeps track of who changed what and when
  • Prevents loosing files and overwriting changes
  • Enables quick and easy rollbacks of changes when necessary
  • Streamlines parallel development of new features
  • Facilitates collaboration with other developers

Great, huh? However, the coolest comes with Continuous Deployments with Buddy. Here is why

Advantages of Continuous Deployments with Buddy

  • Faster delivery of new features and fixes
  • Automation of the delivery process – predictable results with reduced effort
  • Less of everything you dislike: mistakes, pasting and copying, connecting, uploading, memorizing settings, wasting time
  • More of everything you love: progress, momentum, getting things done
  • Sharing project status with everyone around
  • Less complicated development environment – a boost to productivity
  • Higher quality of your software and your life – less bugs, less stress

Bringing Git Version Control to your WordPress theme development

If you are convinced you might give Git a try, let’s move on and create new Buddy project.

Let's get started!

Create new project and select Buddy as your Git provider.

Creating new project in Buddy
Creating new project in Buddy

To complete the next steps of this guide you are going to need the URL of the newly created Git repository (to push new theme files to Buddy). Copy the URL.

Copying the URL
Copying the URL

Create Git Repository on your local machine

Git is a distributed version control system. It means that everyone has their own copy of the project. This copy is just another Git repository stored on your local machine, from which you can push your code to the one that’s been created with Buddy.

Now we are going to create such local Git repository on your machine.

We will be working with the theme named myAmazingTheme. Duplicate an existing WordPress theme directory and rename it to myAmazingTheme.

Now you need to initialize your Git repository. Open myAmazingTheme directory in your Git client and perform this action there. Below you will find an appropriate terminal command.

cd wordpress/wp-content/themes/myAmazingTheme

git init

Next, you need to add the files you want to keep under version control to the repository. The command below will add all files from myAmazingTheme directory to version control.

git add *

Now it’s time to add the repository you created in Buddy as a remote repository for the local repository you’ve just initialized. You are going to need the repository URL you copied while creating new project.

git remote add origin the-buddy-repository-url

As you already know, Git is a distributed version control system. Most operations are performed locally. To communicate with the outside world, Git uses the so-called remotes. These are the repositories other than the one on your local drive. You can push your changes into the remote (so that the other developers can see them) or perform a pull from it (so that you can get others changes).

Push your theme files to Buddy

Once the above steps are completed, you can push your custom theme files to Buddy.

First, commit them locally.

git commit -m ‘hey’

Then push them to Buddy.

git push origin master

Getting it all together:

Initializing Git repository and performing a push
Initializing Git repository and performing a push

Enjoy your WordPress theme development with Git

Since your theme is now versioned in a Git repository, here are some Git basics for you. If you’re already familiar with Git, just skip this chapter and move to the next section.

Any time you create a new file, you need to add it to version control.

git add yournewfile.jpg

To save your work in your local repository at a given point, you have to commit it.

git commit -m ’a nice commit message’

Once you are ready to push the file to Buddy and share with your team or deliver it to your servers, push the change.

git push origin master  

Bringing Continuous Deployments to your WordPress theme development

It’s time to learn how to use Buddy’s pipelines to speed up your WordPress themes development.

Continuous Deployment plan

First, let’s assume that you have one production server, one staging server and one development server. They don’t need to be separate psychical severs – you can just use different directories.

  • Development server is the server where you deploy most often. It’s perfect for sharing work in progress with someone who doesn’t necessarily have their local instance of WordPress, for example with a web designer that designed the WordPress theme but isn’t actually developing it.
  • Staging server is perfect for reviews involving customers or QA team. You deploy there as soon as things get into shape and are ready for internal or acceptance testing.
  • Production server is the machine where the page for the actual users is hosted. Deployments here are the not very frequent and often require prior approvals.

The above approach (employing three servers with different roles) fits projects of any scope – large and small. However, keep in mind that if you decide to organize your work that way, you need to automate certain tasks. And here is where Buddy pipelines come in handy.

To accommodate all the above roles of WordPress instances we’ll create the following pipelines in Buddy:

  • Development pipeline will update the development server automatically on every push, so it will always host the most current version. You won’t need to do anything besides pushing your code to Buddy to show someone your current work in progress.
  • Staging pipeline will be triggered by Buddy recurrently once a day to update the staging server for your customers. It will keep the customers involved in the development process and allow you to follow their feedback since you’ll know which remarks concern a given version.
  • Production pipeline will be triggered only when you decide so by pushing a button. It will update your production server with the version of the theme you choose.

For the purpose of this guide let’s assume that all three WordPress instances are located on the same server, but in different directories, to which different (sub)domains are pointing. In other words we’ll use Apache virtual hosts for our scenario.

Creating the pipelines


On your server create the required visual hosts for all three instances. Let’s assume that you ended up with something like this:


In all public_html directories you should have a copy of your WordPress installation.

Now in each folder create a directory for your custom theme to which you will deploy it. You should now have something like this:


This is all you need to do on your server. Now let’s start creating your first pipeline in Buddy.

Development pipeline

This pipeline will update the development server on every push.

Open Buddy project you created for your theme. Since you don’t have any pipelines yet, you will see a placeholder with a button Build your first pipeline.

Name the pipeline Development, select trigger mode On every push and click the Add a new pipeline button.

Adding your first pipeline
Adding your first pipeline

Next, the list of available actions will appear. Select the upload action that corresponds with your server type (FTP/SFTP/FTPS).

Provide your login details and the path to the theme folder on the server – the remote path. In our case it’ll be:


Once ready, click Test connection & add this action on success button. Buddy will send a test file to your server to check if everything works fine.

Adding first FTP action
Adding first FTP action

Now, as soon as you make a push, Buddy will trigger the pipeline and deploy your theme from scratch. On every next push it’ll only deploy the files that changed.

Since we’ve just made a push and have nothing new to commit, we shall trigger the newly created pipeline manually. To do this, just hit the Run button.

Running the pipeline for the first time
Running the pipeline for the first time

Upon a successful deployment you can log in to your WordPress administration panel and set the new template as active.

WordPress administration panel
WordPress administration panel

Staging pipeline

Now let’s create a pipeline that will update the staging instance according to the schedule, e.g. once a day at 5 pm.

Since we’ve already created the Development pipeline, we can use the cloning feature that will save us some time.

Again, click the Add a new pipeline action on the Pipelines screen and this time select the Clone existing pipeline action in the top right corner.

Since the default values are perfectly fine, just click the Clone actions button. Buddy will create a copy of the selected pipeline.

Now we have to adjust the settings to fit the staging role of the pipeline. Click the pipeline to open it and from the action menu on the right select Change trigger mode, branch & name.

On the edit screen change the pipeline name to Staging and change the mode to Recurrently. This will expand more settings; select 1 day as the Interval and set the start date to Today at 5 pm.

Click Update pipeline to save the changes.

Cloning an existing pipeline
Cloning an existing pipeline

Since you cloned the pipeline, it has the same actions settings as the Development pipeline. This is why we have to change the remote path to folder to which the Staging pipeline will deploy.

While the Staging pipeline is open, select Edit actions, order & add more from the menu on the right.

Open the action and change the remote path to:

Updating pipeline’s action settings
Updating pipeline’s action settings

Production pipeline

Finally we need to deal with the production pipeline, responsible for updating the site for end users.

Let’s repeat the steps we followed in case of the Staging pipeline:

  • Clone the Development pipeline
  • Rename it to Production
  • Switch its trigger mode to manual

Then change its action remote path setting to:

Adding a production pipeline by cloning an existing one
Adding a production pipeline by cloning an existing one


You should have three pipelines on the Pipelines screen.

Three pipelines added and ready to roll
Three pipelines added and ready to roll


We are done – we created new Buddy project and placed the theme files being developed under Git version control. This distributed version control system will now help us keep the work ordered: it will track changes, support automation and collaboration between the developers.

Later, in Buddy, we created three pipelines that will allow continuous deployments approach, with development, staging and production server. Of course this is not the only possible way to employ pipelines – you can configure this flexible tool any way you like.

WordPress themes are just an example of Buddy’s abilities. The above best practices can also be employed while working on WordPress plugins or any other web project.

If you have any further questions, don’t hesitate to contact us at or simply register for the trial version and have a look at Buddy.

Start with a free account if you don’t have an account yet

Join our development automation movement!

Download On-Premises Installation