Lots of companies go to great effort to make website development straightforward for the average user. This makes sense, because there are site owners who don’t have (or want) the time to learn every aspect of running a local site. However, with a bit of research, you can use Git to handle the process of pushing your site live. This gives you a little more security, and once you set everything up, an easier path for making site changes.
Even so, getting to that point is admittedly tough. There are lots of prerequisites to consider, skills you need to have, and tools to hand. Also, you’ll need to think through the process the first few times, because there is a lot to remember. However, using Git to push a site live is possible for almost every user, and it doesn’t have to be as complicated as you think.
For this tutorial, we’re going to show you step by step how to use Git to push a local site to a live server. First, let’s run over some of the tools and technologies we’ll feature in the post.
For the unaware, Git is a Version Control System (VCS). It’s a way to save and record the changes you make on a project – often a app or a website. It’s something we touch on elsewhere, but you’ll need to know more about it for this tutorial.
The typical way to use Git is through a Command Line Interface (CLI) – if you have experience with the WP-CLI, it’s a similar approach. You’ll use commands to mark and organize the files you work on in a number of ways:
It can be more complicated than this, but for the most part you’ll use only a handful of commands to carry out day-to-day work with Git.
Git is a key tool for development teams, because each developer will open a different ‘branch’ within the same repo. This means everyone can work on the project without affecting the files for others. At regular intervals – often as the last task of the day – the team will commit changes to the repo.
A senior member of the team will then look to ‘merge’ all of the branches and changes together to the main
or trunk
of the repo. At this point, you’ll have the definitive set of project files within the repo.
For a single developer – likely you – Git still has value as a kind of incremental saving tool. You’ll open a new branch, work on your site, then stage and commit those changes. It means you can do whatever you like on the branch without affecting any other file on your site. When you want to commit (or delete) you can do so.
Before we move on, we should note that working on your site away from your live server is a recommended typical practice. If you don’t yet do this, check out our piece on how to install WordPress. Also, you might want to consider a dedicated app to work on your site.
Local by Flywheel is a good option, but so is DevKinsta. Regardless, there are lots of ways to create a local site, and it’s something you’ll want to have in place.
The main reason you’ll want to use Git to push your site live is one we mention above: Flexibility. The nature of Git means you’ll have a main branch that serves as the definitive set of project files. However, you can open up as many new branches as you need – indeed, it’s the exact way large teams use Git at scale.
With this approach, you can create a new branch to work on your site’s homepage design, without the need to affect your core files. Consider a branch a kind of clone that you merge back into your main branch through staged commits.
However, there are a few other reasons why Git is useful:
However, to get to this point, you’ll want to have a number of tools, skills, and prerequisites on hand. Next, we’ll go through what they are.
It’s worth noting what you should already have in place before you even think about what extras you’ll need. For example, make sure you have the following to hand:
From here, you can consider what else you need to use Git with your local site and live server:
This should be enough to start, but we’ll mention throughout the rest of the article if something else requires your attention.
There are four steps you’ll need to take to set everything up. Here’s what we’re going to cover:
There’s a lot to get through here, so let’s begin!
While there are a few ways to set up Git repos, we’ll do this using the command line as it’s the most typical way. With a Terminal window open, first navigate to your site’s local directory:
To set up the necessary architecture for your Git repo, run the following commands one at a time:
git init
git add .
The first command will create the directory you need and make it hidden, while the second adds all of the files within your site’s directory to the Git staging area – the period is a ‘wildcard’ modifier:
To see what files are in the staging area, use the git status
command:
From here, you’ll want to carry out an initial commit of these changes to populate your local repo. You do this using the following command:
git commit -m "Initial commit."
The -m
flag tells the command that what follows is your commit message. You’ll need to do this anyway for every commit, and it’s simpler to do so from one place.
From here, you have everything set up on your computer. Next it’s time to work on the remote server.
The process here is similar to your local setup, but requires you to log into your server using SSH. Using this is beyond the scope of this article, but we can point you to a post by Tom McFarlin that outlines the steps you need. Alternatively, you can always ask your host – they should have no issue showing you where these credentials are.
Once you log into your server through the command line, you’ll want to navigate to a private area of your server so that outside users can’t access your Git repo. The directory is often /private/
, although you will want to ask your host about this.
Within this directory, you’ll want to create another directory and navigate to it:
mkdir remoterepo.git
cd remoterepo.git
As long as the directory uses the .git
extension, you can call it whatever you like. From here, initialize a new git repo within the directory, this time using the –bare flag:
git --bare init
This creates the repo you need without the project files, which is secure and recommended.
While you’re in the server, you’ll need to create a file to tell Git where to push changes. First, run the nano hooks/post-receive command
. This opens a command line editor called Nano, and creates the file in the right directory.
Within this file, add the following:
#!/bin/sh
GIT_WORK_TREE=/home/username/example.com git checkout -f
The /home/user/example.com
should point to the exact location of your site’s live files. The username
should be that one you logged into the shell with, and example.com
should be your live site’s domain. Once you do this, save your changes.
The final step here is to set the right file permissions for this file. You can do this using the chmod +x hooks/post-receive
command. The Change Mode (chmod) command is how you set file permissions from the command line – +x
means to set Execute permissions.
Once you do this, type exit
to leave the remote terminal. From here, you’ll need to head back to your local Git repo within the Terminal.
Here, navigate back to your local Git repo using the cd
command as necessary. You’ll need to add a link to your remote server, so that both Git repos can talk to each other. You’ll do this with the following command:
git remote add origin ssh://user@server.example.com/~/remoterepo.git
The exact URL for the Git repo will depend on the location you discovered in the last step. Of course, your user and server credentials will replace the placeholders here.
Run this command, then get ready to push your local changes to your live server. The following command will do this without confirmation, so make sure you want to do this:
git push -u origin main
You’ll see the Terminal display a confirmation summary…
Counting objects: 12, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/1), done.
Writing objects: 100% (13/13), 1200 bytes | 0 bytes/s, done.
Total 12 (delta 0), reused 0 (delta 0)
…and at this point you can check your live site – the changes should be present and correct.
Working on your website is a necessary and often daily task. Using a local environment is the typical way to do so, but there’s a problem – how do you get those changes to your live site that’s error-free and with the least fuss?
The answer could be to use Git to push the changes you make to your live server. This lets you only upload files that you make changes to, so the majority of your installation – and database – stays as it is. While you do need some knowledge and tools to make everything work, it’s a workflow change that could see your local site development skyrocket in productivity and efficiency.
Do you think you’ll use Git to push local site changes live? Let us know your thoughts in the comments section below!
Trying to figure out how to start an online course so that you can share…
Considering using LearnDash to create online course content with WordPress? LearnDash is a popular WordPress…
WordPress XML files see a lot of use for me as a content creator, and…
If you’re looking for a way to deliver an online course, complete with all the…
Search Engine Optimization (SEO) is crucial for any website that wants to maximize its traffic…
Kinsta is a notable brand in the WordPress hosting space. The standout aspect of the…