How to Use Git for WordPress Deployment

Deploying WordPress code manually can become repetitive when you regularly update custom themes, plugins, PHP, JavaScript, or CSS. Git for WordPress deployment provides a more controlled way to track those changes and move tested code from development to staging and production.

Instead of repeatedly uploading files through FTP, you can maintain your code in a Git repository, review changes, test them, and deploy an approved version to your WordPress hosting environment.

Git deployment isn’t available in exactly the same way on every hosting plan, though. Some environments provide SSH and Git access, while others restrict shell access or require you to use a hosting-panel deployment feature. Understanding that limitation before you design your workflow will save you a lot of wasted setup time.

This guide covers how to use Git with WordPress, what belongs under version control, how staging and production fit into the process, where WP-CLI and Composer can help, and how to automate the whole thing once your project outgrows manual deploys.

Is Git Available on Your WordPress Hosting?

Before setting up a Git-based deployment workflow, check what your hosting environment actually supports.

A developer-friendly WordPress hosting environment may provide:

• SSH access
• Git
• WP-CLI
• Composer
• Staging environments
• Server-side deployment access
• Scheduled or automated tasks

Some shared or managed WordPress plans restrict one or more of these. It’s entirely possible to have full WordPress admin access without having shell access to the server itself.

If your hosting account doesn’t provide SSH or Git access, you can still use Git during development and deploy your files through another supported method:

Git repository → local build → FTP/SFTP or hosting deployment tool → WordPress server

The important point is that Git can remain your source-control system even when Git itself doesn’t run directly on the production server. Version control and deployment mechanism are two separate decisions.

Before choosing a deployment architecture, check your hosting provider’s documentation for Git, SSH, WP-CLI, Composer, and staging support — don’t assume a plan includes these just because it’s marketed as “developer friendly.”

Why Use Git for WordPress Deployment?

Git is a version control system that records changes to files over time. For a WordPress website with custom development, it can help you:

• Track changes to themes and plugins
• Review code before deployment
• Maintain a history of changes
• Identify which code version is currently running
• Restore an earlier code revision when something breaks
• Reduce repetitive manual uploads
• Collaborate with other developers without overwriting each other’s work

Git is particularly useful for agencies, developers, WooCommerce projects, and business websites with custom functionality.

One important distinction: Git is version control, not a complete backup system or deployment platform. It manages the files you choose to track. The actual deployment mechanism — manual, script-based, or fully automated — is a separate decision you still need to make.

What Should You Put in Git?

A WordPress installation contains code, media, configuration, and database content. Not all of it belongs in one repository.

Commonly tracked with Git

• Custom themes
• Child themes
• Custom plugins
• PHP files
• JavaScript
• CSS
• Project configuration
• Composer files
• Deployment scripts

Usually managed separately

• wp-content/uploads/
• Cache files
• Temporary files
• Server logs
• Production database dumps
• API keys
• Passwords
• Private SSH keys
• Environment-specific secrets

A basic .gitignore might contain:

wp-content/uploads/

*.log

.env

.DS_Store

This is only an example — your .gitignore should reflect your actual project and deployment architecture, not be copied in blindly.

What About WordPress Core?

There’s no single strategy that applies to every project. Some teams manage WordPress core and dependencies as part of one complete application repository. Others keep core outside their custom-code repository entirely and manage it through the WordPress dashboard or WP-CLI.

For a smaller project, tracking just custom themes, plugins, and project-specific code is usually the easier setup to maintain long-term.

How to Deploy WordPress With Git

A practical workflow looks like:

Development → Git → Staging → Testing → Production

The exact implementation depends on your hosting environment, but the steps below illustrate the general process.

1. Create a Git Repository

git init

Check what Git detects:

git status

Set up your .gitignore before you start adding files, so sensitive or unnecessary files never get committed in the first place.

2. Commit Your WordPress Changes

Review what changed:

git diff

Stage the intended files:

git add .

Commit with a message that will still make sense to you in six months:

git commit -m “Update custom checkout functionality”

3. Push the Code to a Remote Repository

git remote add origin <repository-url>

git push origin main

The repository now acts as the central source for your version-controlled code.

Using Composer for WordPress Projects

For more structured projects, Composer — a PHP dependency manager — can work alongside Git. A project defines its dependencies in composer.json, and committing composer.lock alongside it lets the same dependency versions be reproduced across environments instead of drifting between your machine, staging, and production.

A project might keep:

composer.json

composer.lock

under version control, then have its deployment process install the locked dependencies rather than relying on whatever happens to already be sitting on the server.

For WordPress plugins and themes distributed through the WordPress.org directories, WPackagist mirrors that directory as a Composer repository, which lets you manage those packages through Composer instead of installing them manually.

This approach is more relevant to development teams and larger projects than to a simple brochure site — you don’t need Composer just because you’re using Git.

Using WP-CLI During Deployment

WP-CLI is a command-line tool for managing WordPress — core, plugins, themes, users, and the database — from the terminal instead of the dashboard. It’s useful when your hosting environment provides shell access and you want to script parts of a deployment rather than clicking through wp-admin.

Check the installed WordPress version:

wp core version

Export the database:

wp db export backup.sql

A deployment script might use commands like these to verify an install after a code deploy, or to snapshot the database before a risky change. Treat any database operation on a production site with real caution, scripted or not.

WP-CLI is best thought of as a companion to Git, not a replacement for it — Git handles your code history, WP-CLI handles operational tasks against a live WordPress install.

How Staging Fits Into Git Deployment

Staging is where a lot of WordPress deployment workflows get complicated, because there’s more than one way to wire it up.

Pull-based: the staging server retrieves code from Git directly.

Push-based: a deployment tool or automation system pushes the approved code to staging on your behalf.

Hosting-managed: some WordPress hosts provide a staging feature through their control panel that copies files and database data between staging and production without exposing the underlying Git workflow at all.

Whichever model you use, know which environment is the source of truth. If developers push code changes through Git but someone also edits files directly on the staging server, the two will drift apart silently — and the next deploy can either overwrite that manual work or fail in confusing ways. Staging should be a testing ground, not an uncontrolled second production site.

For the mechanics of setting up and syncing a WordPress staging environment, see CreativeON’s dedicated WordPress staging environment guide rather than trying to cover that broader topic here.

Deploying From Git to the Hosting Server

If your host provides SSH and Git, you can work with the repository on the server directly:

cd /path/to/wordpress

git status

A simple workflow might update the server with:

git pull origin main

But blindly pulling the latest main branch isn’t always the right production strategy — it means whatever’s most recently merged becomes live, tested or not.

A more controlled sequence:

1. Test the code.
2. Approve the change.
3. Identify the specific tested commit or release.
4. Deploy that known version — not just “whatever’s on main.”
5. Run post-deployment checks.

The exact deployment command depends on your Git workflow and hosting setup, but the principle — deploy something you’ve verified, not something that merely merged cleanly — holds regardless of tooling.

Automating WordPress Deployments

Once a project involves more than one developer or more than the occasional code change, manually SSHing in for every deploy starts to cost real time and invites mistakes.

Several platforms can wire repository changes to testing and deployment automatically:

• GitHub Actions — runs build, test, and deploy steps directly from a GitHub repository, and supports named deployment environments (staging, production) with approval and protection rules before a job can deploy.
• Bitbucket Pipelines — the equivalent CI/CD feature for teams already using Bitbucket.
• DeployHQ — a deployment tool built specifically around pushing code to remote servers via SSH/SFTP after a Git push, popular for exactly this kind of WordPress workflow.
• Host-level git-push deploys — some managed and VPS-oriented hosting panels (for example GridPane or RunCloud) let you push directly to a remote tied to your site, which triggers a deploy hook on their end.

A simplified automated flow might look like:

Pull request → Automated tests → Deploy to staging → Manual approval → Deploy to production

You don’t need any of this for every WordPress site. For something small with occasional changes, a manual deploy is often the more sensible choice. Automation starts paying for itself when:

• Multiple developers are contributing code
• Deployments happen frequently
• Tests need to run automatically before anything ships
• Staging and production need a controlled, auditable promotion step
• You need a reliable record of what was deployed and when

What Git Does Not Deploy

Git tracks files. A lot of what makes a WordPress site work lives in the database instead.

A Git deployment does not synchronize the whole website — database changes need their own migration process, separate from your code deploy. WP-CLI’s export/import commands (covered above) are one option for moving database content between environments deliberately, rather than as a side effect of a code push.

Maintain a separate backup strategy for both files and database data — Git deploying cleanly tells you nothing about whether your backups are current.

Common Git Deployment Problems

Hosting doesn’t provide SSH or Git

The most common limitation. If your plan doesn’t include shell access, Git can’t run server-side, full stop. Alternatives:

• Use Git locally and upload the tested files via SFTP
• Use a hosting-provider Git integration
• Use a deployment service like the ones listed above
• Move to a hosting environment that supports the tools your workflow needs

Don’t assume every WordPress plan supports server-side Git — check first.

Production contains uncommitted changes

git status

If the server has unexpected changes sitting in the working tree, investigate before deploying anything on top of them — you could otherwise overwrite a manual fix someone made directly on production, or trigger a merge conflict mid-deploy.

Secrets get committed to Git

Never commit database passwords, API keys, private SSH keys, or auth tokens. Use environment variables or a proper secrets manager instead — and if a secret does get committed, rotating it is not optional even after you remove it from history.

Uploads end up in Git

wp-content/uploads/ grows large fast and changes constantly. Unless your architecture specifically calls for it, keep media out of the code repository entirely.

Database changes get ignored

A code deploy can succeed perfectly while the site still breaks, because a required database change never happened. Treat database migrations as a distinct step from code deployment — never assume one implies the other.

A Practical Deployment Checklist

• Confirm the hosting environment supports the Git/SSH workflow you’re planning around.
• Make sure the working tree is clean before you start.
• Review the actual changes, not just the commit message.
• Confirm the code has been tested — not just that it merged.
• Deploy to staging first when it’s available.
• Check for any required database changes separately.
• Confirm backups are current.
• Keep production credentials out of Git entirely.
• Deploy a known, tested revision — not “whatever’s on main.”
• Test the affected functionality after deployment.
• Record which version or commit is now live.

How to Roll Back a Git Deployment

Git makes code rollback easier because previous revisions stay available in the repository history:

git log –oneline

Identify the last known-good revision, then roll back using whatever mechanism fits your setup — a deployment platform may let you redeploy a previous release directly, while a manual workflow may mean checking out or resetting to a specific commit.

Note that git revert, git reset, and checking out an older commit are not interchangeable — they behave differently and leave your history in different states. Pick the one that matches how your team works with the repository, not just whichever comes to mind first.

A code rollback does not automatically restore database changes, uploaded media, or plugin settings — those need their own recovery steps if a deployment touched them.

Git Deployment Best Practices

• • Keep custom code under version control.
  • Use commit messages that explain why, not just what.
  • Keep secrets out of the repository, no exceptions.

• Use a .gitignore specific to your project.

• Keep development, staging, and production clearly separated.
• Test before production, every time.
• Deploy known, tested revisions rather than the latest branch tip.
• Keep the production working tree clean.
• Use Composer if your project has managed PHP dependencies.
• Use WP-CLI where it simplifies operational tasks.
• Maintain regular backups independent of Git.
• Document database changes separately from code changes.
• Have a rollback plan in place before deploying something significant.

Not every WordPress site needs a full CI/CD pipeline. Pick the simplest workflow that gives you the control your project actually needs — and revisit it as the project grows.

Conclusion

Git is most valuable for WordPress sites with custom code that needs to be tracked, reviewed, tested, and deployed consistently. A practical workflow:

Develop → Commit → Push → Stage → Test → Approve → Deploy → Verify

For simple sites, Git might only be used during development, with files transferred to hosting through another method. For larger projects, SSH, WP-CLI, Composer, and automated deployment tools build a much more structured pipeline on top of the same fundamentals.

The key is not forcing every site into the same setup — check what your hosting environment actually supports first, then build a process that keeps code, database data, media, secrets, and backups appropriately separate.

Frequently Asked Questions