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-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
- 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:
- Create a
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:
# 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
git add README.md
- Commit your
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 firstname.lastname@example.org: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
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 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.cssfile), 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
mainbranch and pull the changes to merge them locally.
git checkout main
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?
functions.php file. Fun, fun!
Until then, water your plants and get plenty of rest. Seriously,
REST isn’t just an API protocol!