Git Version Control (in Local)

Damon Cook Avatar


diagram demonstrating a workflow for promoting code to production on WP Engine

Saving discrete code changes in version control with Git enables you to track the history of changes throughout the lifecycle of a project. Commit your changes (early and often) to Git and push them to a remote GitHub repository to deploy them to a targeted, specific environment (Development, Staging, or Production) and collaborate with anyone from anywhere. After you’ve shipped a new feature and want to get all the latest data from the production site, you can use Local’s Connect and sync what you want when you want.

This post is part of a series that helps set up an end-to-end workflow for developing sites.

Notice how I put “(in Local)” in parenthesis? Local does not offer any integration with Git version control or GitHub, for that matter. However, our WordPress codebase exists because Local generates the WordPress core files for us and stores them on your computer. We want to focus on taking some of those files and directories and putting them under Git version control while intentionally ignoring the rest. This allows us to keep a discrete history of changes to our codebase.

There are many ways to go about how to version control and organize your Git repository. Consider using Composer to manage your WordPress plugins and theme dependencies or utilize WP Engine’s Smart Plugin Manager service to auto-update your plugins and themes.

It is also worth noting that you can rely on WP Engine’s WordPress core auto-updates or test and manually trigger WordPress core updates yourself (either in WP Engine’s portal or in your site’s WP admin dashboard), but we won’t cover including WordPress core files in our version control.

Ultimately, it is a matter of what works best for you and your team, and WP Engine aims to offer the flexibility to meet most teams’ workflow needs. Mostly, we encourage you to keep your Git repository lean because it’ll help keep your GitHub Action deployments shorter. The more plugins you add (and files) to your repository will increase the time it takes to run a deployment, which can create a counter-productive side-effect for your team.

If you’ve been following along, you should have the Yoast SEO plugin and Frost theme installed on your Local site, which we will continue to work with for this end-to-end demonstration.

Telling Git what to ignore

It is crucial to tell Git what you want to keep a history of and what you want to ignore. There is a particular file that Git uses to maintain this list of allowed and disallowed files and directories. It is called the .gitignore file.

If you’ve been following along then your Local site’s wp-content/ directory likely looks like this:

WordPress plugins directory with Yoast SEO plugin installed and the standard index.php file.
WordPress themes directory with the Frost theme installed and the standard index.php file.
wp-content/upgradeWhere WordPress often stores backup info when running upgrades.
wp-content/uploadsWordPress media library uploads directory.
A standard fresh install of WordPress has these folders within the wp-content directory

In our case, we only want to track the wordpress-seo plugin and frost theme directories with Git.

So, let’s create a new file in VSCode (or your editor of choice) called .gitignore , add the following necessary rules to allow and disallow the pertinent files and folders, and save the .gitignore within the wp-content/ directory, which is the root of our Git repository.

Below is the complete code for our .gitignore.

wp-content/.gitignore (full source)

# This Git ignore should be located
# in your WordPress install's wp-content/
# directory.

# WordPress general

# WordPress themes

# DO NOT ignore these themes...

# WordPress plugins

# DO NOT ignore these plugins...

# WP MU plugins: these are
# managed by the platform.

# WP uploads directory

# WP upgrade files

# OS-specific files

# Composer

# Smart Plugin Manager

# large/disallowed file types
# a CDN should be used for these

# Build tools

# Other
Code language: YAML (yaml)

Note the highlighted lines above (lines 18 and 26). These show the precise lines where we’re telling Git not to ignore the Yoast SEO plugin, Frost theme, and everything else ignored by version control.

Initialize Git (in Local)

Now that we have a proper .gitignore file in our wp-content/ directory. We have to initialize Git. Right now, Git does not exist, nor is Git aware that this folder is intended to be a repository. So, let’s initialize Git. (Note: We won’t cover how to install Git on your computer, but here is a handy guide.)

There are many options for initializing Git, and we’ll cover a few.

GitHub Desktop (free)

A typical application for setting up Git version control is GitHub’s own GitHub Desktop, which allows you to drag and drop a folder into its application, choose ‘create a repository,` and give it a name. You can even select a Git Ignore file to jump-start your repo’s configuration, but we already have one.

So, go ahead and drag the wp-content/ folder on GitHub Desktop, choose ‘Create a repository,’ give the repository a name, and click the ‘Create Repository’ button. This will even give us an initial commit, which is handy.

Demonstration of adding a folder in GitHub Desktop
Demonstration of adding a folder in GitHub Desktop

How do you find your Local site’s wp-content/ folder? We can use Local’s ‘Go to site folder‘ to get to where Local installs the WordPress site, but we will still have to navigate further into app/public/wp-content/.

Demonstration of using the Go To Site Folder button in Local
Demonstration of using the Go To Site Folder button in Local

Command-line interface (CLI)

If you’re a regular CLI user, you likely already know how to cd to the wp-content/ directory and run git init.

If you’re still new to CLI, here is another way to switch to the wp-content/ directory. Open up Terminal, iTerm, or Hyper, and type cd (with a space after “cd”) and then drag and drop the folder into the CLI app and hit ‘Return.’ This will drop you right into the corresponding directory.

Demonstration of drag and dropping a Finder directory into iTerm app and running git init
Demonstration of dragging and dropping a Finder directory into iTerm app and running `git init`

Publishing Git to GitHub

At this point, you should have Git initialized in your Local site’s wp-content/ directory and tracking changes to only the Frost theme and the Yoast SEO plugin. That is fine and dandy, but we want our Git history available to other developers and clients (optional). We want to publish our repository to GitHub so you can reap the rewards of a centralized codebase and version control.

Again, we’ll show you how to do this with CLI and GitHub Desktop.

Publishing with GitHub Desktop

GitHub Desktop makes it pretty easy to publish your changes if you already have a GitHub account set up. If you don’t, then you better get started!

Just click the ‘Publish repository’ in the top-right, which should prompt you to sign in to by opening a browser and completing the process. Once logged in, give your GitHub repository a name and click ‘Publish.’

Publishing with CLI

There are two ways to go about this:

  1. Adding a local repository to GitHub with GitHub CLI
  2. Adding a local repository to GitHub using Git

What’s next?

Let’s explore adding WP Engine’s GitHub Actions to trigger branch-based deployments to targeted environments with our existing demonstration codebase.