Skip to main content
DevOps Insightsguides & answers

Git · troubleshooting

error: Your local changes to the following files would be overwritten by merge

git pull stopped because you have uncommitted edits to files the incoming commits also change, and merging would overwrite them. Commit them, stash them around the pull, or discard them if you do not need them.

Reproduced on Git 2.50.1, . Where the text says “reproduced”, the behaviour was run on that version, not taken from documentation.

First published

New to this? Read what is actually happening first, then come back to the steps.

On this page · 9 sections

Before you start

  • A terminal in the repository.

Run this first

step 1 of 2
git status --short

Look for M or ?? entries

Lists uncommitted changes; the files named in the error are the ones that collide.

Work out which cause you have

A few questions to narrow the list. Every answer ends in a command that confirms or rules the cause out — this cannot see your cluster, so nothing here is a certainty until you have checked.

Narrow it down

0 answered · nothing is sent anywhere

Do you need the local changes to the files listed?

Cause space

2 of 2 still possible

  • You want to keep your editsCommon
  • You do not need the local editsOccasional

Nothing ruled out yet. Answer the question above and the branches your answer eliminates will strike through here.

Or diagnose it manually

In this order. The first command usually contains the whole answer.

  1. Step 1

    git status --short

    Lists uncommitted changes; the files named in the error are the ones that collide.

    Look for M or ?? entries

  2. Step 2

    git fetch && git diff --stat HEAD..@{u}

    Shows which files the incoming commits change, to compare with your edits.

    Look for The same file in both lists

Every cause, and how to fix it

Ordered by how often each one turns out to be the answer.

You want to keep your edits

Common

The local change matters. Either commit it so the pull merges both, or shelve it around the pull.

Confirm

git status --short
git diff --stat

M next to the file named in the error

Fix

  • Commit, then pull: git add FILE, git commit -m "…", git pull. Resolve any conflict the merge reports.
  • Or stash around the pull: git stash, git pull, git stash pop. If the pop conflicts, fix the markers in the file; the stash is kept until you git stash drop it.
  • Or in one step: git pull --autostash, then check git status for UU files, because it exits 0 even when re-applying conflicts.
git stash && git pull && git stash pop

Reproduced on Git 2.50.1; a conflict on pop keeps the stash, so nothing is lost.

You do not need the local edits

Occasional

A generated file, a temporary debug change, or an edit made by a tool. You want the remote version.

Confirm

git diff FILE

Changes you are sure you can lose

Fix

  • Discard that file's changes and pull: git restore FILE (or git checkout -- FILE), then git pull.
  • If a tool keeps changing a tracked file, stop tracking it or add it to .gitignore so it stops blocking pulls.

Understanding it properly

Skip this if you are mid-incident — the working part of the page is above. Worth reading afterwards, because understanding the mechanism is what stops the next one.

In plain terms

You edited a file and have not committed it. Meanwhile someone pushed a change to the same file. Pulling would replace your version of that file, so Git refuses and changes nothing. You decide what happens to your edits: keep them as a commit, park them while you pull, or throw them away.

Words used on this page

Working tree
The files on disk, including edits you have not committed.
Stash
A shelf for uncommitted changes: git stash saves and removes them, git stash pop puts them back.
Autostash
git pull --autostash stashes your changes, pulls, and re-applies them in one step.
What is actually happening

Reproduced on Git 2.50.1: with an uncommitted edit to a file the remote had also changed, git pull printed error: Your local changes to the following files would be overwritten by merge, listed the file, said Please commit your changes or stash them before you merge, then Aborting, and exited 1. Nothing was changed.

Edits to files the incoming commits do not touch never cause this; only overlapping files do.

Stashing is safe even when your edit and the incoming change collide. git stash, git pull, git stash pop produced a merge conflict in the file and The stash entry is kept in case you need it again, so the edit was still recoverable.

git pull --autostash does the same in one step. With a collision it printed Applying autostash resulted in conflicts. Your changes are safe in the stash. but exited 0, leaving the file in conflict (UU in git status): a script that checks only the exit code will miss it. Without a collision it printed Applied autostash. and nothing was left in the stash.

How to tell this is your problem
WhereWhat you see
git pull or git mergeerror: Your local changes to the following files would be overwritten by merge: FILE … Please commit your changes or stash them before you merge. Aborting
git checkout or git switcherror: Your local changes to the following files would be overwritten by checkout: FILE
git statusmodified: FILE under Changes not staged for commit

How to know it is actually fixed

  • git pull completes, and git status shows no UU (unmerged) files.
  • Your edits are back in the file, committed or restored from the stash.

Stopping it happening again

  • Commit or stash before pulling, especially in a shared clone.
  • Keep generated and machine-local files out of Git, with .gitignore, so they never block a pull.

Security considerations

  • git checkout -- FILE and git reset --hard delete uncommitted work for good; there is no stash or commit to recover it from. Use them only when you are sure.

Sources

Behaviour described here is drawn from official documentation. Where a figure could not be confirmed on an official page it is attributed in the text rather than stated as canonical.

Did this get you to an answer?

No text box on purpose — please do not paste production logs anywhere

Something wrong or out of date? Report it