How to Deploy WordPress Changes With Git

If you regularly update a custom WordPress theme or plugin, manually uploading files to your live website can become difficult to manage. Git provides a more controlled way to track code changes and deploy approved versions to your WordPress hosting environment.

With a Git-based workflow, you can make changes, test them, commit the working version, and then deploy that version to production.

This guide explains how to deploy WordPress changes with Git, with a focus on cPanel-based WordPress hosting.

How Git Deployment Works for WordPress

A typical WordPress Git deployment workflow looks like this:

Develop

   ↓

Test

   ↓

Commit changes

   ↓

Push to Git repository

   ↓

Deploy approved code

   ↓

Verify live WordPress website

The Git repository stores the code you want to manage. The deployment process then copies the required files into the appropriate production directory.

For a custom WordPress theme, for example:

Git Repository

      ↓

.cpanel.yml

      ↓

wp-content/themes/my-theme/

      ↓

Live WordPress website

The exact deployment path depends on your repository structure and hosting configuration.

What Can You Deploy With Git?

Git works best for WordPress code that you actively develop and maintain.

This distinction is important because Git is a version-control and code-deployment tool, not a complete WordPress synchronization system.

Changes stored in the WordPress database need a separate process.

For example, changing functions.php can be deployed through Git, while changing the content of a WordPress page through the dashboard normally changes the database.

Before You Start

Before setting up Git deployment, make sure you have:

• A working WordPress website
• A Git repository
• Git installed on your development computer
• Access to your hosting account
• A production directory identified
• A recent WordPress backup
• A testing or staging process

If you use cPanel, your hosting provider must also have Git Version Control enabled. This feature is not always on by default — many shared hosting plans have it turned off, so check with your host first if you don’t see it under Files, or you may spend time troubleshooting a feature that isn’t actually available on your plan.

Step 1: Create Your Git Repository

Start by creating a repository for the WordPress code you want to deploy.

For example, a custom theme might have a structure like:

my-wordpress-theme/

├── style.css

├── functions.php

├── index.php

├── header.php

├── footer.php

└── assets/

Initialize Git in the project directory:

git init

Add your files:

git add .

Create a commit:

git commit -m “Initial theme version”

You can then connect the project to a remote Git repository such as GitHub or another Git-compatible service.

The repository should contain the code you actually intend to deploy rather than an uncontrolled copy of the entire WordPress installation.

Step 2: Add a .gitignore File

A .gitignore file prevents unwanted files from being committed to your repository. For a WordPress project, a generic .gitignore isn’t as useful as one scoped to what you’re actually deploying — usually your theme and plugin code, not WordPress core or uploads.

A practical pattern used in many WordPress Git deployments ignores everything by default, then whitelists only the code you maintain:

# Ignore everything except:

/*

!.gitignore

!.cpanel.yml

!.htaccess

!wp-content/

wp-content/*

!/wp-content/themes/

!/wp-content/plugins/

!/wp-content/languages/

# Never track these even inside themes/plugins:

.env

*.log

.DS_Store

node_modules/

/wp-content/uploads/

Adjust the specific paths to match your own theme or plugin names and directory structure.

Never commit passwords, API keys, private credentials, or other sensitive information.

For WordPress, uploaded media (the wp-content/uploads/ directory) should also normally be excluded — it’s large, changes constantly, and isn’t code you’re versioning.

Step 3: Test and Commit Your Changes

Before deploying anything to production, test the changes.

For example, after modifying a custom theme:

git status

git add .

git commit -m “Update homepage layout”

Only commit code that is ready to move to the next environment.

A simple workflow might be:

Feature change

     ↓

Local testing

     ↓

Code review

     ↓

Approved commit

     ↓

Production deployment

You don’t need a complicated branching strategy for a small WordPress website, but production should contain only tested code.

Step 4: Connect Git to cPanel

cPanel provides Git Version Control under:

cPanel → Files → Git Version Control

The interface allows you to create or clone repositories and manage their deployment.

There are two main deployment approaches:

1. Push deployment
2. Pull deployment

Both are officially supported. Push deployment happens automatically as soon as a .cpanel.yml file is present and you push to the cPanel-managed repository, since cPanel adds a deployment hook to every managed repository by default. Pull deployment is a manual, opt-in step you trigger from the cPanel interface. Neither is universally “the recommended” approach — which one fits better depends on how much control you want over the exact moment code reaches production (more on this in Step 6).

Step 5: Configure .cpanel.yml

This is one of the most important parts of cPanel Git deployment.

A cPanel-managed repository must contain a valid .cpanel.yml file in the top-level directory before deployment is available. The file tells cPanel what commands to run and where to deploy the files.

For example:

—

deployment:

  tasks:

    – export DEPLOYPATH=/home/user/public_html/wp-content/themes/my-theme/

    – /bin/cp style.css $DEPLOYPATH

    – /bin/cp functions.php $DEPLOYPATH

    – /bin/cp index.php $DEPLOYPATH

This is only an example. Replace the path and files with those appropriate for your own project.

If your repository contains a complete theme directory, you may instead deploy the required directory structure, for example with /bin/cp -R.

Important: Do Not Copy Everything Blindly

Avoid using a wildcard that copies the entire repository without considering what is inside it.

cPanel specifically warns against using a wildcard such as * because this can copy the .git directory and create problems.

Your deployment commands should deliberately specify what belongs in production.

A note on file permissions

Copying files with .cpanel.yml preserves the permissions and ownership of however they land on the server, which occasionally differs from what your web server expects — particularly if a task runs as a different user than your site’s normal file owner. If a deployed page looks fine in Git but throws a permissions error live, check ls -l on the deployed files before assuming the code itself is broken.

Step 6: Choose a Deployment Method

Option 1: Push Deployment

Push deployment is useful when you want an approved push to the cPanel-managed repository to trigger deployment automatically.

The basic workflow is:

Local computer

      ↓

Git commit

      ↓

git push

      ↓

cPanel-managed repository

      ↓

.cpanel.yml

      ↓

Production website

cPanel adds a post-receive hook to its managed repositories. When changes are pushed to a properly configured cPanel-managed repository, the deployment commands in .cpanel.yml run automatically.

For example:

git push -u origin HEAD

The important point is that the destination in this workflow is the cPanel-managed repository, not simply any remote Git repository.

This is a good fit when you trust that anything reaching that branch is production-ready and you don’t want a manual step between commit and live site.

Option 2: Pull Deployment

Pull deployment is useful when your main repository is hosted remotely, such as on GitHub.

The workflow is:

Local computer

      ↓

GitHub repository

      ↓

cPanel: Update from Remote

      ↓

cPanel-managed repository

      ↓

Deploy HEAD Commit

      ↓

Production website

In cPanel:

1. Open Git Version Control.
2. Select the repository.
3. Click Manage.
4. Open the Pull or Deploy section.
5. Click Update from Remote.
6. After the repository is updated, click Deploy HEAD Commit.

cPanel documents this as the manual, pull-based deployment workflow. It does not automatically deploy every update in this configuration — you decide when the repository is updated and when the deployment actually runs.

For many WordPress websites, this approach provides useful control because you can decide when a remote change reaches production, separate from when it was merged or pushed upstream.

Do You Need SSH Access?

Not necessarily.

If your hosting account provides cPanel Git Version Control, you can perform many repository management tasks through the cPanel interface. Specifically, without shell access you can still create, clone, delete, and view repositories through the interface.

However, SSH becomes necessary when you need to:

• Run Git commands from the command line
• Troubleshoot Git problems
• Configure advanced deployment commands
• Work with private repositories that require key-based authentication
• Manage files or deployment processes directly on the server

Your hosting provider controls whether SSH access is available on your plan.

Deploying From a Private GitHub Repository

If your WordPress code is stored in a private GitHub repository, the hosting environment needs appropriate permission to access it.

One common approach is an SSH key or GitHub deploy key. A deploy key is an SSH key that grants access scoped to a single specific repository, rather than to your whole GitHub account — which makes it a safer option for server-side automation than using a personal account key.

Do not place GitHub passwords or private credentials inside your repository.

The exact authentication method should depend on your hosting environment and security requirements.

Step 7: Verify the Deployment

After deploying the code, don’t assume the website is working simply because Git reports a successful deployment.

Check the live website.

At minimum, test:

• Homepage
• Navigation
• Theme layout
• Forms
• JavaScript functionality
• Important landing pages
• Login functionality
• WooCommerce checkout, if applicable

Also check for PHP errors or other application errors if something appears broken, and check file permissions if a page that renders correctly in Git behaves unexpectedly live.

If your website uses WordPress, server-level, plugin-level, or CDN caching, clear the relevant cache when necessary.

For caching-specific guidance, link to your WordPress Caching Guide rather than explaining caching in detail here.

What Happens to Database Changes?

This is one of the most important limitations of WordPress Git deployment.

Suppose you make two changes:

• Change A: Modify functions.php.
• Change B: Add a new page through the WordPress dashboard.

Git can track Change A because it is a file change.

Git does not automatically track Change B because the page content is stored in the WordPress database.

The same applies to many:

• WordPress settings
• Plugin settings
• WooCommerce products
• Orders
• Users
• Posts
• Pages

Therefore, don’t assume that deploying a Git commit makes two WordPress environments identical.

For complete website transfers, use a dedicated WordPress Migration Guide.

For database and website recovery, use your WordPress Backup Guide.

How to Roll Back a WordPress Git Deployment

One major advantage of Git is that you can identify previous versions of your code.

If a deployment introduces a problem, you can return to a known working commit and deploy that version again.

A simplified workflow is:

Current deployment

       ↓

Problem discovered

       ↓

Identify previous working commit

       ↓

Restore/redeploy code

       ↓

Test website

However, Git rollback has an important limitation.

Rolling back code does not automatically roll back the database.

For example, if a deployment changed a PHP file and also required a database migration, restoring the previous Git commit only restores the tracked files.

It does not automatically undo the database migration.

This is why significant WordPress deployments should have both:

• Version-controlled code
• A reliable backup and recovery process

Best Practices for WordPress Git Deployment

Test Before Production Use a local or staging environment to test changes before deploying them to the live website.

Keep Secrets Out of Git Never commit:

• Passwords
• API keys
• Private SSH keys
• Database credentials
• Other production secrets

Deploy Only Required Files Your .cpanel.yml file should deploy the files your production website actually needs.

Keep Deployments Small Smaller, focused deployments are easier to test and troubleshoot.

Back Up Before Major Changes Git protects tracked code, but it is not a replacement for a complete WordPress backup.

Keep Production Stable Only deploy code that has been tested and approved.

Verify After Deployment Check important pages and functionality immediately after deployment, including file permissions if something looks broken without an obvious code cause.

Have a Rollback Plan Know which commit represents the last stable version and understand how you would restore it.

Common Git Deployment Mistakes

Deploying the Entire WordPress Installation You usually don’t need to place every WordPress core file, upload, and database-related component under Git. Focus on the code you maintain.

Forgetting .cpanel.yml Without a valid .cpanel.yml in the repository’s top-level directory, cPanel deployment functionality will not be available for that repository.

Using the Wrong Deployment Path A successful Git operation can still result in a broken website if files are copied to the wrong directory. Always verify your WordPress installation and target directory.

Deploying Untested Code Git makes deployment easier, but it doesn’t make bad code safe. Test before production.

Committing Sensitive Information Never use your Git repository as a storage location for passwords or production secrets.

Assuming Git Deploys the Database It doesn’t. Plan database changes separately.

Using Git as Your Only Backup Git can help restore tracked code, but it isn’t a complete WordPress backup solution.

Ignoring File Permissions After Deployment A deployment can succeed at the Git level and still leave files with the wrong ownership or permissions for your web server. Spot-check permissions on the deployed files, especially after changing hosting configurations or deployment scripts.

Is Git Deployment Suitable for Every WordPress Website?

Git deployment is especially useful for:

• Custom WordPress websites
• Agencies managing multiple sites
• Developers maintaining custom themes
• Custom plugin projects
• Websites with regular code updates
• Teams working on WordPress code

It may be unnecessary for a simple WordPress website where most changes are made through the WordPress dashboard.

The more custom code your website contains, the more valuable version control becomes.

Frequently Asked Questions