Up Your WordPress Game with Git

If you want to level-up your WordPress game, start using Git. Git is a version control system that helps you track changes to your codebase. With Git, you can test out new features using branches, create remote repositories on GitHub, and keep track of your commits with the log.

This post assumes you already have a working knowledge of Git and GitHub. But if you are new to these technologies, I highly recommend you check out Amy Dutton’s Git series.

My WordPress Git Workflow

When I first started developing, I felt really confused about which files to commit in version control. With some practice, I not only got the hang of it, but I also had a lot of fun along the way!

Which Files Should I Track?

In version control land, you’ll often hear foreboding tales of committing API keys and sensitive files that the public shouldn’t see. So, which files should you even track when developing WordPress sites?

To answer that question it’s important to understand the two-part structure of the WordPress app.

Database. WordPress uses a MySQL database to persist data like posts, users, and settings. I recommend that you don’t commit the database to version control. Doing so will expose user data and the database can grow very large, making it cumbersome for your team over time.
Files. At the root of your WordPress install, you’ll see some core files and folders like wp-includes, wp-config.php, and wp-admin. You normally will not need to worry about committing the WordPress core files to version control. Rather, if you are developing a child theme like we’ve been doing in this series, you should to track the changes you make inside the child theme’s directory.

How Do I Get Started?

Okay, so you know that you will typically only commit the changes you make in your child theme directory. Now what?

Create your remote repository.

I like to use GitHub, but you can use any remote repository service you’d like. So, in my GitHub account, I’m going to create a repository called groovy.

Initialize your local repository.

Start up Local on your computer, and navigate to the root of your child theme folder we created in the previous article. Now initialize your Git repository with this terminal command:

git init

Create a README.md file.

The README file can provide whatever information you’d like. Larger projects will have detailed steps on spinning up a local environment, while smaller projects have less thorough documentation. For a child theme, I typically create a README like this:

++>README.md<++


# Groovy New Site

## About
This repository contains the child theme files for Groovy. 

## Versioning
This repository utilizes semantic versioning. The current version can be found in the child theme's [style.css](style.css) file.

Stage your README.md for commit.

git add README.md

Commit your README.md.

git commit -m "Initialize git repo."

Update the primary branch’s name.

Git’s default name for the primary branch is master. I’m actively looking for ways to be more inclusive in my code, so I like to modify the primary branch name at the start of every project:

git branch -M main

Add your remote repository.

You’ll need to add your GitHub repository as a remote in order to push commits up to it. Grab the SSH path from GitHub and add it like so:

git remote add origin git@github.com:sarmstead/groovy.git

You can call your remote whatever name you’d like. Above, the remote’s name is origin, but I’ve also used gh and github in the past to help myself better understand where the code is being pushed to.

Push the local code to your remote.

git push -u origin main

The command above does two things. First, it pushes all commits from your local main Git branch to your remote called origin. Next, it sets the origin remote as the default branch with the -u flag (also referenced as --set-upstream). Having your remote as the default branch allows you to run git pull from the main branch in your local directory without having to specify the remote.

How to Work with Branches

From here, you could technically commit all changes to your local main branch and push them to your origin remote. However, I recommend using branches to better manage your project and keep track of new features. Here’s how I like to do that:

Create a new feature branch and switch over to it.

git checkout -b features/style-hero-section

The code above is a shortcut for creating a branch and switching over to it at the same time. In this case, I’ve named the branch features/style-hero-section. features allows me to quickly know the purpose of the branch, and style-hero-section allows me to know which particular feature is implemented in the commits.

After making your changes (in this case, to the style.css file), add them to staging and commit them.

git add style.css

git commit -m "Add hero section styles."

Push your commits to the remote.

git push origin features/style-hero-section

Your process from here may look slightly different depending on the service you’re using for your remote repository. In my case with GitHub, I will now see a new branch called features/style-hero-section. I then can create a pull request to merge the changes into the main branch in the remote repository.

After merging changes in the remote, switch to the main branch and pull the changes to merge them locally.

git checkout main

git pull

You can delete your feature branch now (git branch -d features/style-hero-section), or simply leave it as is.

Final Thoughts on Security

When you’re ready to deploy your local changes to production, make sure to remove the .git directory. This is because “an attacker can extract sensitive information by requesting the hidden metadata directory that version control tool Git creates.”

If you’re using Local for your development environment, the software automatically removes the .git folder for you.

Where to Next?

Now that we have Local and Git set up, we have the tools in place for a solid WordPress development workflow. In our next tutorials, I’ll show you how I use Git to add JavaScript to our child theme and modify our functions.php file. Fun, fun!

Until then, water your plants and get plenty of rest. Seriously, REST isn't just an API protocol!