Push & pull problemsAlways fixable

Fix 'Your local changes would be overwritten by merge'

Git won't let me pull because of local changes — how do I fix it?

Short answer

Git is refusing to overwrite uncommitted edits to files the incoming commits also change. Commit them, stash them, or discard them — stashing is the reversible choice and takes one command.

quick fix

git stash push -u -m "before pull"
git pull
git stash pop

Park your changes, pull, then put them back

Does this match your situation?

'error: Your local changes to the following files would be overwritten by merge.'
'Please commit your changes or stash them before you merge.'
'error: cannot pull with rebase: You have unstaged changes.'

Step-by-step fix

See what's actually in the way
Git names the specific files it won't overwrite. Look at them before deciding — sometimes they're edits you meant to keep, sometimes they're debug leftovers you'd happily discard.
step 1
```
git status
git diff
```
Option A — stash, pull, restore
The safest route and the one to reach for by default. Your changes are stored as real commit objects, so even if the restore goes wrong nothing is lost.
step 2
```
git stash push -u -m "wip before pull"
git pull
git stash pop
```
If stash pop hits a conflict, resolve it as normal — the stash stays on the stack until it applies cleanly.
Option B — commit first
If the changes are finished work, just commit them. The pull then merges or rebases them like any other commits.
step 3
```
git add .
git commit -m "Work in progress on inventory"
git pull --rebase
```
Option C — let Git do it automatically
Autostash performs the stash-pull-restore dance for you, every time. Set it globally and this error largely stops happening.
step 4
```
git pull --rebase --autostash

# make it permanent:
git config --global rebase.autoStash true
```
Option D — discard the local changes
Only when you're certain the edits are worthless. This overwrites your files with the committed versions and cannot be undone.
step 5
```
git restore .
git pull
```

Why this works

Merging and rebasing both need to update files in your working directory. If a file has uncommitted edits and the incoming commits also change it, applying them would silently destroy your work — and since those edits were never committed, nothing could recover them. So Git stops. It's the same protective instinct behind the non-fast-forward push rejection: refuse the operation rather than lose data that exists in only one place.

How to stop it happening again

Set rebase.autoStash true globally so routine pulls stop tripping on this.
Commit or stash before pulling, as a habit.
Keep unrelated local tweaks out of tracked files — use skip-worktree or a local-only config file.

Commands used in this guide

git stash

Park uncommitted work temporarily so you can do something else.

git pull

Fetch from the remote and immediately integrate the changes into your branch.

git restore

Throw away working-directory changes or unstage files (the modern, clearer replacement for checkout).

git commit

Record everything currently staged as a permanent snapshot.

git config

Read and write Git settings for one repo, your user, or the whole machine.

Still stuck?

Search the full command reference and every other rescue guide — there are 56 of them, covering everything from detached HEAD to force-push disasters.

Browse all guides →

Frequently asked questions

Why can't I pull with uncommitted changes?

Because the incoming commits modify the same files you've edited, and applying them would overwrite work that exists nowhere else. Git refuses rather than destroy uncommitted changes. Commit, stash, or discard them and the pull proceeds.

What is the fastest safe fix?

git stash push -u, then git pull, then git stash pop. It takes seconds and everything is recoverable — stashes are real commit objects, so even a mistake here can be undone.

Can I make Git handle this automatically?

Yes — git config --global rebase.autoStash true. Git then stashes your changes before a rebase or pull and reapplies them afterwards, without you doing anything.

Related rescue guides

Always fixable

git pull says I need to specify how to reconcile divergent branches — what do I choose?

Git 2.27+ refuses to guess whether you want a merge or a rebase when both sides have new commits. Pick one — git config --global pull.rebase true gives you clean linear history and is the best default for most people.

Read the fix →Always fixable

How do I undo a git pull?

A pull is a fetch plus a merge or rebase, so undoing it means moving your branch back to where it was. git reset --hard ORIG_HEAD does exactly that, because Git saves your pre-pull position there automatically.

Read the fix →Rarely recoverable by Git

How do I throw away all my local changes in Git?

git restore . discards edits to tracked files and git clean -fd deletes untracked ones. Both are irreversible for anything that was never staged or committed, so run git stash first if there's any doubt — it takes a second and makes the whole operation undoable.

Read the fix →Always fixable

My push was rejected — 'Updates were rejected because the remote contains work that you do not have'. What now?

Someone pushed commits you don't have yet, so your push would erase them. Git is protecting you. Fetch and integrate their work first with git pull --rebase, then push again. Never reach for --force here unless you genuinely intend to delete what's on the server.

Read the fix →

← All Git Rescue guides