Using Git in cPanel without wrecking WordPress

You can use cPanel Git Version Control with WordPress when you deploy into a chosen path and keep live uploads and config out of the repo. The tool is meant for code you control, such as a custom theme or plugin, not for initializing a repository on top of a running public_html tree. Pick a deploy directory and a branch first, then point the site at that code only after a clean pull.

Choose a path before you connect the repo

Create or select a folder that is not your only copy of production uploads. Deploy the branch there, test the site, and only then switch the document root or promote from staging. Do not run git init inside a live wp-content directory you have already edited in File Manager. Uploads and wp-config.php do not belong in Git if you want a recoverable store.

Before any pull, confirm what the working tree actually is:

git status; git remote -v

git status shows untracked or dirty files such as uploads, cache, and local config that a careless clean would remove. git remote -v confirms the remote matches the project you intend to deploy. Avoid git clean -fdx on a tree that still holds media; those files are deleted from disk, and you will need a backup restore if they were not elsewhere.

Ignore the right files and use a deploy key

Keep a solid .gitignore for wp-config.php, the uploads directory, cache folders, and vendor if you build dependencies on the server. Prefer a deploy key limited to that repository instead of tying the account to a personal GitHub login. Run Git as the same system user that owns the site files so you do not spend hours fixing ownership after a pull.

Composer may be available on shared hosting, but large installs can time out. For heavy trees, build artifacts in CI and deploy the result rather than compiling everything on the account.

After a pull that breaks the site

A 500 error after deploy is often a missing .htaccess or a wp-config.php that never lived in the branch. Check the error log before you blame PHP itself. Never force-push over production media, and say clearly whether uploads sat inside the tree if a pull wiped the site so support can look at the right backup set.

On WordPress accounts you can still use WP Toolkit for core and plugin tasks while Git handles only the custom code path you chose. AutoSSL continues to cover the domain on cPanel once the document root is correct again.