Git Stash Apply Conflict, How to Resolve Safely

A conflict when applying a stash means the changes you stashed away overlap with changes made to the same lines since you stashed them — Git needs your help deciding how to combine them, and importantly, a failed apply doesn't delete your stash, so there's no risk of losing the stashed work while you sort it out.

The Problem

You stash your changes, do some other work (or pull updates), and when you try to bring the stashed changes back, Git reports a conflict instead of cleanly applying them:

git stash pop
Auto-merging src/app.js
CONFLICT (content): Merge conflict in src/app.js

The file now shows conflict markers, and it's not immediately obvious what the safest next step is, especially since stash pop is involved rather than a normal merge.

Why It Happens

A stash conflict happens for exactly the same underlying reason as any merge conflict — the same lines of a file were changed both in the stash and in the current working state (through commits made since stashing, or a pull that brought in new changes), and Git can't automatically determine which version should win. Common scenarios:

• You stashed changes, then committed unrelated work on the same file that happened to touch nearby or the same lines
• You stashed changes, pulled updates from a teammate that modified the same lines, and now the stash conflicts with the newly pulled code
• You applied the same stash more than once without realizing it, causing the second application to conflict with changes the first application already introduced

The Fix

The most important thing to understand first: if you used git stash pop and it resulted in a conflict, the stash is not automatically dropped in this case — Git keeps it in the stash list specifically because the pop didn't cleanly succeed, protecting you from losing that work while you resolve things. Confirm it's still there:

git stash list

Resolve the conflict the same way you would for any merge conflict — open the conflicted file, look for the conflict markers, and edit the file to the correct final state:

<<<<<<< Updated upstream
existing code
=======
your stashed code
>>>>>>> Stashed changes

After manually resolving each conflicted section and removing the markers, stage the resolved file:

git add src/app.js

Since the stash is still in your stash list (it wasn't dropped due to the conflict), explicitly drop it now that you've manually incorporated its changes, to avoid accidentally applying the same stash again later:

git stash drop

If you'd rather take a more cautious approach — reviewing the stash's changes without immediately trying to merge them into your current state — apply the stash into a fresh, disposable branch first, so you can inspect it in isolation without any risk to your current work:

git stash branch temp-review-branch

This creates a new branch from the commit where you originally stashed, then applies the stash on top of it, avoiding a conflict against your current branch's more recent state entirely — useful specifically when you want to review the stashed changes cleanly before deciding how to integrate them.

Still Not Working?

If you're unsure whether you've fully resolved the conflict correctly and want a safety net before committing, use git diff to review exactly what the resolved file now contains compared to both versions, confirming the final merged result actually reflects your intent rather than accidentally keeping the wrong side of the conflict:

git diff --cached

If something looks wrong after resolving, and the stash hasn't been dropped yet, you can always abort your current changes and start the conflict resolution over from scratch, since the stash itself remains safely intact until you explicitly drop it.