Fixing “Your local changes would be overwritten by merge”

You run git pull, expecting a quiet update, and Git throws this at you instead:

git pull origin master
remote: Enumerating objects: 14, done.
remote: Counting objects: 100% (14/14), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 14 (delta 8), reused 14 (delta 8), pack-reused 0
Unpacking objects: 100% (14/14), done.
From github.com:user/repo
 * branch            master     -> FETCH_HEAD
   953146e..9f38420  master     -> origin/master
error: Your local changes to the following files would be overwritten by merge:
 List of your local files ...

That error means you have uncommitted changes in your working directory that clash with what you are about to pull in. git pull runs fetch and merge, and — as Git’s own documentation confirms — it does not discard your local changes to make room for the incoming commits; it stops before that happens, which is exactly why you see this message instead of silently losing work. Here is why Git stops you, three ways to fix it, and the one command I actually use.

Why Git Blocks the Pull: Uncommitted Local Changes

git pull runs git fetch and then, by default, merges the fetched branch into your current one — that is documented behaviour, not an implementation detail. A merge has to combine changes from both branches, and if your uncommitted edits touch the same lines as the incoming commits, Git cannot work out which version you want. Rather than guess, it stops and shows you the error instead of quietly overwriting your work.

Solutions: How to Git Pull and Keep Local Changes Without Losing Your Work

You have three options, depending on what you want to do with your local changes:

1. Stash your changes. Use git stash to temporarily save your changes and restore a clean working directory, then pull. Afterwards, run git stash apply or git stash pop to bring your changes back.
2. Commit your changes. If you are happy with them, commit with git commit first, then pull as normal.
3. Discard your changes. If you do not need them, git reset --hard HEAD wipes out your uncommitted changes so the pull can proceed. This is destructive — the working-directory changes are gone for good, so check with git status or git diff first.

Quick checklist before you pull:

• Want to keep the changes and merge them in later? Stash, or use --autostash (below).
• Happy with the changes as they are? Commit them first.
• Do not need them? git reset --hard HEAD, then pull.
• Not sure what you are about to lose? Run git status or git diff before doing anything destructive.

All of that works, but there is one command that does the whole dance for you:

git pull --rebase --autostash

It updates your local branch with a rebase instead of a merge, and automatically stashes and restores your local changes around it.

The result looks like this:

Created autostash: 9bd05c7
HEAD is now at 3ea660f minor formatting changes
First, rewinding head to replay your work on top of it...
Applying: minor formatting changes
Applied autostash.
(base) X$ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)
  ...

Here’s what each part of the command does:

1. git pull fetches from the remote and, by default, merges the result into your current branch — Git’s own docs describe it as running git fetch followed by an integration step. Add --rebase and it uses rebase instead of merge for that step.
2. --rebase tells Git to replay your local commits on top of the fetched remote branch instead of merging, which keeps history linear. It is documented as part of git rebase, and git pull accepts it directly.
3. --autostash automatically stashes your uncommitted changes before the rebase starts and reapplies them once it finishes, so you can run the whole thing on a dirty working directory.

git pull --rebase --autostash is the one I reach for whenever I have uncommitted work and want the remote changes without a manual stash-pull-pop cycle. It can still hit conflicts if your local edits and the incoming commits touch the same lines — you will need to resolve those by hand before the rebase completes, same as any rebase.

Final thoughts

🔒 Subscribe to keep reading.

References

🔒 Subscribe to keep reading.