Pause automatic deployment and record the error. Keep a backup of the repository and any live files it deploys. Ask other administrators whether they edited production files directly or created local commits.

1. Open the repository’s management view and confirm the branch and remote. In an authorised shell within that repository, run git status to identify the state, git diff for unstaged changes, and git diff --cached for staged changes.
2. Distinguish tracked code edits from untracked uploads, caches and environment files. Do not commit secrets or user data merely to clear the status.
3. Preserve legitimate code changes in a reviewed branch or patch and reconcile them through the normal development workflow.
4. Correct the deployment layout if the application writes runtime data into tracked release files. Move such data into supported persistent locations or exclusions.
5. Once the working tree and branch are intentionally reconciled, retry the update and inspect the new commit before deploying.

From the intended repository in an authorised terminal, these commands summarize its current state without resetting or deleting files:

git status --short
git diff --stat
git diff --cached --stat

git diff --stat summarizes unstaged tracked-file changes. git diff --cached --stat summarizes changes already staged for the next commit. A blank first summary does not prove the repository is clean. Review the corresponding full diff privately before preserving or reconciling code, and keep credentials and user uploads out of commits.

The update should complete without losing local work, and the resulting diff should match the intended release. Verify the remote URL did not change unexpectedly.

A hard reset or clean command can discard data, so do not use one as the default answer to a pull error. If a merge has begun and conflicts appear, resolve or abort it through Git’s supported workflow after preserving relevant changes.

Often the deployment directory doubles as an application data directory or administrators edit files directly on the server. Separate code releases from mutable data and make the reviewed repository the source for code changes.

• Cloning a private Git repository through cPanel
• Deploying a cPanel Git repository with .cpanel.yml
• Rolling back a Git deployment while preserving uploaded data
• Adding an SSH public key to a cPanel account

• Git: Git Status
• Git: Git Diff
• cPanel: Git Version Control