How to force a git pull and overwrite local files

You are on a server, a few files in the working copy have been edited by hand, and all you want is the state from the repository — exactly as it is in origin, no merge, no questions. The command most people look for is git pull --force. It exists, but it does not do this. The flag goes to git fetch and only allows references to be updated in a non-fast-forward way; your local files are not its business.

Two commands do the job.

The two steps

git fetch --all
git reset --hard origin/main

git fetch --all loads the current state of all remotes without touching your files. git reset --hard then moves your branch to that state and overwrites every tracked file on the way.

If the branch is not main, name it:

git reset --hard origin/<branch_name>

Not sure what the current branch tracks? This prints it:

git rev-parse --abbrev-ref --symbolic-full-name @{u}

The error that reset does not fix

A pull on a server often fails like this:

error: Untracked working tree file 'data/file.php' would be overwritten by merge.

The word that matters is untracked. Git does not know this file, so git reset --hard leaves it alone and the next pull fails again. Untracked files need their own command:

git clean -n -d    # dry run: shows what would be deleted
git clean -f -d    # deletes untracked files and directories

Always run the dry run first. And be careful with -x: it also deletes files listed in .gitignore — which on a live server is typically .env, uploaded media or a local configuration. That is how a quick fix turns into a restore from backup.

Save your work first

git reset --hard and git clean -fd both delete without asking. Two seconds of insurance:

git stash -u                      # keeps tracked and untracked changes
# or
git branch backup-$(date +%F)     # keeps the current commits under a name

With the stash you can look at the discarded state later using git stash show -p, or bring it back with git stash pop.

For deployments

If you deploy by pulling into a working copy, make the reset part of the deploy script instead of a manual rescue action:

git fetch --all
git reset --hard "origin/$BRANCH"
git clean -fd        # without -x, so .env and uploads survive

That gives you the same result on every run, no matter what somebody edited on the server. The cleaner path is to build elsewhere and ship the result, so that the server holds no git repository at all — but as long as you do pull on the server, the three lines above are the honest version of “force pull”.

Frequently asked questions

Is there a real git pull --force?

The flag exists, but it does not overwrite your files. It is passed on to git fetch and only allows a non-fast-forward update of local references. To make a working copy match the remote you need git reset --hard, and git clean for untracked files.

Why does git reset --hard not remove the file in the error message?

Because the file is untracked: git does not know it and therefore does not touch it. Only git clean -fd removes untracked files and directories.

I just lost a local commit. Can I get it back?

Usually yes. git reflog lists where HEAD pointed before the reset, and git reset --hard <hash> goes back to that state. This only works for committed work; uncommitted changes that were not stashed are gone.

What is the difference to git checkout -- .?

git checkout -- . restores tracked files from the current commit, so it undoes local edits but keeps your branch where it is. git reset --hard origin/main also moves the branch to the remote state, which is what you want after a fetch.