Use git to develop WordPress sites with a team of coders

By /

If you work with a team of coders, you’ll want to use git to develop WordPress sites, themes, and plugins.

Even if you’re the only developer working on a WordPress site, you’ll want to maintain a history of all the changes you make to your site’s custom code, using a source code control tool like git.

If you’re working in a team, this history of changes is especially important.

By keeping a record of each version of your site’s code, you can restore your work if anyone on the team introduces a show-stopper bug, or overwrites a file.

That’s why you need to use version control software, like git, to develop WordPress sites.

These types of software tools (also called “source code control”)

help a software team manage changes to source code over time … Version control protects source code from both catastrophe and the casual degradation of human error and unintended consequences.

What is version control | Atlassian Git Tutorial

Remember, it’s always important to fight against “casual degradation,” in source code, at least.

Using git

This guide doesn’t teach you how to use git, but it teaches you how to use git with WordPress.

If you aren’t familiar with git or source code control, first take some time to familiarize yourself with at least the basic concepts, and learn how to create a code repository on GitHub or BitBucket, and how to push and pull changes using your favorite git tools.

There are lots of great lessons and tutorials about using git out there, and great tools for developers to integrate git into their development environment (two of my favorites are Visual Studio Code and Atom).

To get started with git, you can check out our free guide on how to create a new public repository on GitHub without using the command line.

If you don’t want to learn all the commands for the dread command prompt, there are also GUI tools for GitHub or BitBucket to help you manage your code repositories.

Go ahead and learn the basics of how to use git. I’ll wait…

Great! You’re back. By now, you should know the basics of git and source code control, like:

  • The location where all of your source code is stored is called a repository (or repo for short).
  • Your repo is comprised of at least one branch, the master branch, but you may fork your repo to create multiple branches.
  • To work with your git repo, you’ll pull, commit, and push your files.
  • You can put any kind of file into your repo, but git works best with text files (like source code, for example).
  • You can exclude files from your repo with the .gitignore file.

If these terms don’t make sense, take a moment to go back and learn the basics of git.

But if these terms do make sense, you’re ready to use git to develop WordPress sites.

Do I have to use git and GitHub?

No. You can use any version or source code control system you want to manage your WordPress source code.

But, since the WordPress development team uses GitHub, and git is one of the most popular source code control tools, I’ll just use “git” as a short synonym for “the version control tool you’re using.”

You can also use any code repository server you want. This includes GitHub, BitBucket, or your own code repository server.

I’ll use GitHub as an example, but feel free to pick your own — use the one that’s best for your team.

Using git to develop WordPress sites

If you’re working on a development team and hacking reams of C++ source code files, it’s obvious what to add to git source code control: your source code!

You might also want to add some script files, notes, and other source code and configuration files. That’s pretty easy to figure out.

Not so with a WordPress project. A new WordPress installation includes many files and folders, plus lots of media files (images like .png and .gif files, maybe other media like .mp4 or .pdf files).

Also, there’s a WordPress database file somewhere you need to copy, as well.

To understand exactly which WordPress source files you want to put under source code control, you need to understand how a WordPress site is set up on your server. This server can be a development, staging, or production server — it doesn’t matter.

Let’s look at the site structure from the point of view: what parts of the site change, and what parts don’t (or shouldn’t)?

Which source code files (like .php, .js, .css) should you place under version control, and which can you safely ignore.

A WordPress server setup: parts of a WordPress site

Let’s look at the parts of a working WordPress site to determine what we can manage with git source code control.

At the highest level, a WordPress server hosts:

  • the WordPress database.
  • WordPress files (including code and media).

The WordPress database

The WordPress database is already managed by a database server, like MySQL or Marimba (this depends on your server configuration).

Don’t use git to manage your WordPress database, even though it might be a text file.

The database file changes often, and can grow to become quite large. It’s best to use git with many small files — like, say, source code files.

Also, using git to revert a database file to an older version can introduce all kinds of problems.

Instead, use database tools, like phpMyAdmin, to backup your database. You can also use wp-cli to export your database, or a backup plugin to make a copy.

It’s a good idea to back up your WordPress database at least once a day, using some kind of automated tool.

The WordPress database is arguably the most important single file in your WordPress setup, so you can’t have too many backups.

The WordPress software or your database administration software should make changes to your database file.

It’s a bad idea to edit the database file directly. Therefore, it’s not a good candidate for version control.

Besides, the WordPress database server is already set up to handle multiple users (for example, all the different accounts in your WordPress site).

So, let’s leave the WordPress database aside, and look at how we can use git with the files in your WordPress website.

WordPress files

Let’s take a look at the files and directories installed on a WordPress server and organize them by the frequency of changes, and who’s changing them.

Here’s a list of the files and directories in a brand new WordPress installation:

 index.php
 license.txt
 readme.html
 wp-activate.php
 wp-admin/
 wp-blog-header.php
 wp-comments-post.php
 wp-config.php
 wp-config-sample.php
 wp-content/
 wp-cron.php
 wp-includes/
 wp-links-opml.php
 wp-load.php
 wp-login.php
 wp-mail.php
 wp-settings.php
 wp-signup.php
 wp-trackback.php
 xmlrpc.php

Only some of these files are good candidates for source code control. Let’s group these files based on how they change, if they should change, and who has permission to change them.

The three categories of WordPress files are:

  • the wp-config.php file that stores the settings and configuration for a specific site, including how to access the database.
  • the WordPress core files: the exact set of files that are installed when you first create your site, and will be updated when you update WordPress.
  • your site’s unique content files, including plugins, themes, and uploads, all contained in the wp-content directory.

Note that if your site has been hacked or compromised, your WordPress site may also contain another category: malware files. Unless you’re a computer forensic specialist or security researcher, you don’t want to add malware to your git code repository.

Before you add your code to a repository, make sure it’s clean and doesn’t include malware. Better yet, rebuild your site on a development server to ensure it’s virus free.

Don’t add these files to your git code repository

Let’s eliminate all the types of files you don’t want to add to your code repository.

wp-config.php

Because the wp-config.php file contains the server specific settings for your WordPress installation, don’t put your wp-config.php file in your git repository — here’s why:

  • Since the wp-config.php contains the server specific user name and password to connect to your WordPress databse, you don’t want to share this sensitive set of credentials with anyone who doesn’t need it. It’s a massive security risk to add your wp-config.php file to your git code repository! Don’t do it.
  • One of the best reasons to use git with WordPress is so you can easily set up a copy of your site on a development server, make your changes to the source code, and then share them back to the code repository. This means your development server will have its own, unique, wp-config.php file. If you put the wp-config.php into your code repository, it can overwrite your local wp-config.php file and break your development site.

So, just back up your wp-config.php file separately and securely. After your WordPress site is set up and you’ve confirmed it works, there’s rarely a reason for anyone except the site admin to change anything in wp-config.php.

Also, wp-config.php is one of the primary targets for WordPress hackers, so you can’t back it up enough. But back up wp-config.php to some place safe, to prevent unauthorized access or accidental deletion.

The WordPress core files

You don’t want to make changes to the WordPress core files. Therefore, you don’t need to add them to your git code repository. Here’s why:

  • You can always grab a fresh copy of the WordPress core files from wordpress.org to ensure your site is running the latest version of WordPress. No backup required!
  • When you update your version of WordPress using the Adminstrator Update page (or wp-cli), the update will overwrite the outdated WordPress core files. This is exactly why you don’t want to change these files, either: any edits you make will be overwritten the next time you update the site.

What exactly are the WordPress core files? It’s easiest to describe them by what they aren’t:

  • as noted above, wp-config.php isn’t really part of the WordPress core files, even though it’s part of the initial installation, because it isn’t altered when you install a WordPress update. Instead, it contains settings that are specific to your server.
  • The files in the /wp-content directory are where you’ll find the specific files that make your WordPress site unique: plugins, themes, and uploads.

The “uploads” directory

You’ll find the uploads directory inside of the /wp-content directory. Inside this directory (/wp-content/uploads), you’ll find all of the media you’ve uploaded to your site, organized by year and month.

Like this:

 wp-content/uploads/
 └── 2019
     └── 07

These are the media files you’ve added to pages and posts. These files include:

  • images like .png, .gif, and .jpg files.
  • other media like .pdf or .mp4 files

These files are unique to your site, so you need to back them up. But, your uploads folder should never contain code!

Code files include .php, js, .sh, and other script files that instruct your server to execute commands. There’s no reason for these types of files to be in your uploads directory.

If you find code files in your uploads directory, it probably means your site’s been hacked. Time to clean that up!

Keep in mind that your media files aren’t source code, but instead are (relatively) large static files that don’t change once you’ve uploaded them. This means they are poor candidates for version control.

Instead, use a backup plugin or script to back up the uploads folder automatically. Because these files don’t include security credentials, you can share them widely with your development team, unlike wp-config.php.

Great ways to share the uploads directory include:

  • Zipping up the uploads directory and sharing it on a web, FTP or file sharing server, and then sending out the link to the dev team.
  • Using rsync or SFTP to grab a copy of the files in the uploads directory.

This leaves just the plugins and themes directories, inside of wp-content, to place in your git code repository.

Let’s look at each individually.

Use git to develop WordPress plugins

If your team is coding a custom plugin, you definitely want to use git to develop WordPress plugins.

But you don’t want to use git to manage other plugins you’ve installed from other, third-party sources.

Only use git to manage your plugins if you are writing a custom plugin!

The /wp-content/plugins directory contains all of the plugins installed in your WordPress site, active or deactivated.

If you’re just using plugins that you’ve downloaded or licensed, there’s no reason at all to put these plugins in your git source repository.

You don’t want to change the code in a plugin file that’s maintained by someone else: just like with the WordPress core files, any changes you make will be overwritten and lost as soon as you update the plugin.

Pro tip: using wp-cli, write a simple shell script to install all the plugins you need for your specific WordPress installation.

If you’re developing a custom plugin, create a project repository for it on GitHub (you can also use BitBucket or your own git server if you prefer). This way, you can give only your plugin development team access to the code.

If your plugin contains some media files, they’re probably small and need to be included, so add them to your repository, even if they’re not files you’ll change often. That way, your dev team can find all the files they need to work on the plugin in one place.

Pro tip: use your .gitignore file to keep development files out of your repository, like .tmp or cache files, that you might generate during development.

Use git to develop WordPress themes

Just like your site’s plugins, if all of your themes are from third-party developers, don’t put them under source code control!

You don’t want to change the code in a third party theme, because your changes will be vaporized as soon as the theme is updated.

But, if your team is working on customizing the appearance of your WordPress site, you’ll want to use git to develop WordPress themes or child themes.

Use git to develop WordPress child themes

WordPress child themes are the preferred way to modify an existing theme to preserve your changes when the parent theme is updated by the third-party theme developer.

Use git to manage the code in your custom child theme.

Because your child theme is stored in a separate directory from the parent theme, it’s easy to add only your child theme directory to a new git source repository.

Use git to develop WordPress themes from scratch

If you’re building a new WordPress theme from scratch, or based on a simple starter theme like “_s” then use git to manage the code in your custom theme.

Just like your code repository for a custom plugin, your custom theme repository will benefit from a .gitignore file, to filter out unwanted development, temporary, and cache files.

Also, do incorporate theme-specific media in your theme repository, so your development team can find everything in one place.

But what if I want to use git for the entire wp-content directory?

Just because adding the entire wp-content directory isn’t the most efficient use of git with WordPress, that doesn’t mean you can’t do it. There are advantages of putting all of wp-content into your git repository:

  • All of the files that make your site unique (except for wp-config.php — which should never go into your git repo) will be tracked in your repo.
  • It’s easy for a developer to recreate your site. All they need is a) a copy of the site’s WordPress database; b) a fresh installation of the WordPress core files; and c) access to the git repo that contains wp-content.

But there are some disadvantages, too:

  • The files in /wp-content/uploads are typically much larger than all of the other files in wp-content since these files are typically larger images and other media files.
  • If you’re using a shared repository at GitHub or BitBucket, your costs may go up significantly if you need a lot of storage space.

So, weigh the pros and cons for your team’s unique situation. If everyone is working at the same physical location, or if you have the technical ability (or good devops skills) you can set up your own git server and keep costs to a minimum.

Also, if you want to put your entire wp-content directory in a git repo, your probably don’t want to share the repo with the public. Instead, set up your repo as private and only give access to the developers on your team.

TL;DR: only use git to develop WordPress custom plugins and themes

You don’t want to use git source code control for:

  • your WordPress database
  • wp-config.php
  • the uploads directory (unless you can set up your own git server, or don’t mind paying extra for more storage)

It’s potentially expensive, or even disastrous, to manage these files with git source code control. Instead, back up these site-specific files with the backup tool(s) of your choice.

Also, there are a number of files on your site that you don’t want to change at all, and can be easily replaced or updated. These include:

  • the WordPress core files
  • third party plugins and themes

This just leaves two types of files for git version control:

  • custom plugin directories, and
  • custom or child theme directories.

In both cases, set up a separate code repository project for each plugin, theme, and child theme. This way,

  • You can decide whether the project is private, or publicly available (if, say, you release your code with a GPL licence).
  • The project is focused and easier to understand.
  • You won’t be able to add any strange dependencies to your code repository
  • You can manage the team for each project separately.

Alternatively, if you want to set up your own git server, or pay extra for storage, you can put the entire wp-content directory into your git repo — but you probably don’t want to share this repo as a public project.

Related Posts

Scroll to Top