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?

If you’re seeing this error

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.

You’re in the right place — the fix is below.

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

  1. 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

  2. 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.

  3. 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

  4. 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

  5. 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 76 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 stash pop hit a conflict — how do I resolve it, and can I undo it?

Good news first: a conflicted pop never drops the stash, so your work is still safe in the stash list. Either resolve the markers and then git stash drop manually, or back out entirely with git checkout . followed by a fresh git stash apply once the tree is clean.

Read the fix →Always fixable

Git says 'You have not concluded your merge (MERGE_HEAD exists)' — how do I get unstuck?

A merge you started is still open. Decide one of two things: finish it by staging the resolved files and committing, or throw it away with git merge --abort. Everything else is blocked until you do, because Git will not start a second operation on top of an unfinished one.

Read the fix →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 →
← All Git Rescue guides