Stop Using FTP: A Practical Guide to Git Push for WordPress

I got a call from a new client in a panic. Their site was down. White screen of death. Turns out, their previous developer had been updating a critical plugin by dragging and dropping files over FTP. He uploaded the new version to the wrong folder, and boom. Total mess. After we fixed it, the first thing they asked was, “How do we make sure this never, ever happens again?” The answer is simple: use a sane deployment process. For a lot of WordPress sites, that means learning how to use git push with WordPress.

Forget complex continuous integration pipelines for a minute. For 90% of the sites out there, a full CI/CD setup is like using a sledgehammer to hang a picture. It’s overkill. The real problem is moving away from manual, error-prone FTP uploads. That’s the real killer.

Your Server is Just Another Remote

Here’s the kicker: if you’re already using Git (and you absolutely should be), you’re 99% of the way there. Most developers are used to pushing their code to a remote repository on GitHub or Bitbucket. But a remote doesn’t have to be a fancy service. It can be any server that understands Git. Including your web server.

The whole concept of using git push for WordPress deployment boils down to this: you add your production server as a named remote repository. Then, when you’re ready to deploy, you just push your main branch to it. That’s it. No more dragging files and praying you got the right directory. Some managed hosts like WP Engine and Pantheon have this built-in, which is great. But if you’re on your own VPS, it’s not hard to set up yourself, a concept I first saw detailed over at carlalexander.ca.

Setting Up Your Git Push Workflow

First, you need SSH access to your server. This is non-negotiable. Once you’re in, you’ll initialize a bare Git repository somewhere outside your public web root. For example, in /var/repo/site.git.

$ ssh user@yourserver.com
$ git init --bare /var/repo/site.git

A “bare” repository is just the .git guts without a working copy of the files. The magic comes from a post-receive hook. This is a script that runs automatically after the push is complete. Inside your bare repo, you’ll create a file at hooks/post-receive.

#!/bin/sh
git --work-tree=/var/www/html --git-dir=/var/repo/site.git checkout -f

Make that script executable with chmod +x hooks/post-receive. This hook tells Git: “Once you receive the code, take the files and place them in the /var/www/html directory (your web root).” Back on your local machine, you add your server as a remote:

$ git remote add production ssh://user@yourserver.com/var/repo/site.git

Now, when you want to deploy, you just run:

$ git push production main

So, What’s the Point?

The point is reliability. And sanity. This process isn’t just about convenience; it’s about making your deployments predictable and safe. Every single deployment follows the exact same steps, driven by a single command. No more “whoops, wrong folder” moments that take a client’s site offline.

• It forces you to version control everything. No more guessing what code is live.
• It’s fast. Way faster than any FTP client.
• It provides a clear history of what was deployed and when.

Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.

Is it the most advanced deployment system in the world? No. But for a huge number of WordPress projects, it is the perfect blend of simplicity and power. It solves the core problem—unreliable manual changes—without adding a mountain of complexity. Trust me on this, it’s a solid first step to a better workflow.