When I started building websites, I “cowboy coded”, which means I was often editing files live on the server. It only took me a few broken sites to realize this was a terrible idea. Then I started building sites locally on my computer. More than once I edited a local file only to migrate the file to the wrong location in my FTP client. Occasionally that would mean I’d overwrite a file that I couldn’t fix without digging around for some backup copy I had hopefully kept.
If you’re still dealing with FTP and not being able to roll your files back, then it’s time to learn about using Git for version control.
What is Version Control?
A version control system (VCS) is a type of software that helps software developers manage changes to their code over time. A good VCS system will keep track of each change in the code that is made. This means if you break something, you can roll back to a previous version of the code that was working, without trying to hit “Undo” until things work.
In a team environment, a VCS will help you work with different members by giving you tools that will allow you to merge changes in code together when different members update files.
One of the things that I do in Git is to create a new branch for each feature I build. This means I can keep track of the changes I make on a branch, but still get back to the current state of the site by moving back to the main branch. We’ll talk more about this workflow later.
What is Git?
Git is a version control system, but it’s not the only one. The main WordPress repository is run via SVN, though you can find a Git copy as well. There is also Mercurial, Visual Source Safe, VESTA, and many other options.
Despite all these options, Git is what almost everyone uses so it’s the version control we’re going to learn about today.
Basic Git Terms and Commands
Before we dig into the mechanics of how to use Git, we need to understand a few terms. We’re only going to cover the terms that you’ll encounter regularly.
Add: When you’ve made changes to your code you will use the command git add to add the changes to so that they can be committed.
Branch: A branch is a version of your repository that has a difference from the main working project. All repositories come with a main or, more commonly in older projects a master branch. Recently Git, and Github have started to change the default branch name from master to main due to the historical issues with the word master. Git 2.28 also allows you to set your default branch name for any new project.
Checkout: You use the
git checkout command to switch between different branches in a repository. When you use this command, Git changes the contents of the files or adds and removes files that differ between branches.
git clone command is used to make a copy of a repository from the source repository. You’d use this command to get a local copy of a remote repository so that you can work on the code.
Commit: Once you’ve used
git add you need to use
git commit to be able to save the state of your files in git.
git init creates an empty repository for you with all the basic files that Git needs to operate.
Merge: Once you’ve made changes on one branch and added and committed them, you use the git merge command to migrate those changes into other branches.
Origin: This is the default name for the primary version of the repository. I usually change mine to be more descriptive than origin though. If I’m working with Github then I change the settings in Git so that origin becomes github. This helps me keep things clear in my head.
Push: Updates the remote branch with the commits that have been made in your local version of the repository.
Repository: This may also be called a “Repo” and is a directory of all the files, and a Git history of changes to those files.
git status shows you the current status of your working repository.
.gitignore: This is a hidden file that contains patterns of files that Git will not bother tracking. If you have
.DS_Store in your
.gitignore files then it will ignore all the pesky files that macOS often puts inside folders.
Hosting Git Repositories
One other thing to understand before diving in is that, while you don’t need a remote location for your repository, not having one will reduce some of the benefits of using Git. Without a remote repository hosted somewhere else, you won’t have a backup of your code if your computer dies or gets stolen.
Github and Bitbucket are two of the more popular places to host your Git repositories because they’re mostly free, and you can have private repositories. That does mean your code is on someone else’s server so if you don’t like that idea, you can use Gitlab on your server to host repositories.
On macOS, the simplest way to install git is to open Terminal and type git which will prompt you to download Xcode Command Line tools to install git. Once that has finished you can run git –version to see which version of git you have. If that’s not working, there are a few other ways to install git on macOS.
For Windows users, you can install Git with the official Git installer. Git also comes bundled with the Github Desktop application, which we’ll talk about later.
If you’re on Linux, git should be bundled with your package manager, or you can look at these ways to install git on Linux.
Configuring Git Defaults
Once you have Git installed, you need to configure it so that each commit uses your name and email and commit messages to use your preferred editor to enter any comments that go with the commit. We’ll look at the way to set these in macOS via the Terminal application.
git config --global user.name "Your Name" will set the name that goes with every commit made on your computer.
git config --global user.email "firstname.lastname@example.org" will set the email address that is associated with every commit you make.
git config --global core.editor vim will make the default editor for Git vim. While I love vim, it’s not the editor that everyone loves. If you use Atom then you’d use git config –global core.editor “atom –wait” or git config –global core.editor “subl -n -w” for Sublime Text.
Establishing a Repository
Now that we have git installed and configured, let’s start a basic repository. Open your Terminal and create a folder called test-repository by typing
mkdir test-repository. Then type
cd test-repository to change into your test-repository directory and type
At this point, you’ll have one hidden directory in your folder called
.git. Since it’s a hidden file you’ll need to type
ls -a in Terminal to list hidden files.
Using git add
Now let’s create a file by typing
touch test.txt into Terminal. Next type
git status to see the file you just added.
As you can see the new file we created shows up in red and tells us that its status is untracked. That means that Git sees the file, but doesn’t have any record of it.
git add test.txt to tell Git to stage this file, then type
git status again and Git should tell you that it knows about a changed file.
Committing Files to Git
Now that we’ve added our file we need to commit it so that Git saves the status of the file. We can do this in a single line, without opening our default editor with the following command.
git commit -m 'adding our first file'
-m tells git that the words inside single quotes is the comment that goes with the command.
Now our repository has a single file in it with its status saved.
Create a Branch
The real power of Git comes when you start to get into branching. Let’s say you want to write a bunch in your test.txt file but aren’t sure if you will end up keeping it and want to make sure you can get back to the currently blank file. We can do this with a branch.
To create a branch we can type
git checkout -b new-branch. This is a shortcut to create a branch at the same time as we checkout the branch, and it’s what I use every time I need to create a branch.
Now open our
test.txt file, add some text to it and save it. Then use
git add and
git commit as above to save the state of the file.
git checkout master to switch back to the default main branch and then look at the contents of your
test.txt file again. You’ll notice that all the text you typed has been removed. Git would even delete a new file that was only on one branch, though it does keep a record of it so it’s not gone.
Merge a Branch
Now, we love whatever it was we wrote in our file, so let’s integrate it with our main branch. Make sure you’re on the main branch and type
git merge new-branch to integrate your changes.
If you look at the contents of
test.txt now you’ll find your changes on the main branch just as you left them.
Using Git with WordPress
While the example above was extremely simple, that’s all you need to get started with Git in your projects. So let’s talk about exactly how you get a WordPress project using Git.
The first consideration is what level in your folder hierarchy should be the root of your Git repository. If you’re building a theme, then you could make the theme folder your repository. The same logic applies if you’re building a plugin.
I usually am working in themes and plugins at the same time so I often use the wp-content folder as the location for my repository. When I do this I make sure to ignore the uploads folder so that I don’t add all the images and uploaded files to the repository. They clutter up the repository and can slow Git down because it’s not great at compressing image files.
If I’m handling an entire deployment workflow, then I make the root WordPress folder the main location for my Git repository. Then I make sure to add
wp-config.php to my
wp-config.php is specific to each WordPress install, so I don’t want it deployed over any other version of the file which would cause the site to stop working.
You can see a copy of the
.gitignore file I use as a starting point for every project. It assumes that you’re using
wp-content as the root of your Git repository, so I change some of the ignore patterns if I’m at the root of WordPress.
Git GUI Applications
While we’ve covered the basics via the command line for Git, not everyone is comfortable in the command line, I know I wasn’t when I started using Git. Even now, occasionally I want to look at a visual representation of what Git is doing before I make any changes to my setup.
Luckily there are several great GUI clients for Git that you can use so let’s highlight a few.
Github Desktop (Windows/macOS)
One great spot to start as you look at Git GUI clients is with the Github Desktop application.
Many open-source projects use Github as their code repository for collaboration and use the standard Github flow to do their work. The Github Desktop client is built to help you handle this flow so it’s going to make creating pull requests easier.
If you’re not sure what a pull request is, check out Github’s documentation on pull requests
Unfortunately for Linux users, there is no official Github Desktop application, but there is a fork of Github Desktop that will install on Linux systems.
Git Tower (Windows/macOS)
The Git GUI I use is Git Tower. Git Tower is available for macOS and Windows. When I was getting started with Git, I found it way easier to resolve conflicts and see what was different between files inside this GUI.
Working Copy (iOS/iPadOS)
If you mainly work from an iPad, as I do, then you should look at Working Copy. Working Copy is a full-featured Git client that works with iOS and iPadOS. It even features Shortcuts integration so you can automate parts of your Git workflow.
While we’ve covered a lot of ground in your Git knowledge today, there is no way a single blog post could be exhaustive on the topic. You can continue your learning with the Nexcess help documentation as well as these excellent resources.
By using Git to manage your client projects, you will save yourself headaches since you can roll back changes or discard entire branches if you no longer want the work you’ve done. No more Ctrl + Z until you think you’ve rolled back far enough, Git will keep track of it all for you.