Git Stash Not Working? The Four Fixes Nobody Teaches You

When people say git stash is not working, they almost never mean the command is broken. They mean it did something they didn't expect: their new files survived the stash, pop exploded into conflicts, or a stash they swore they made isn't there. Stash has exactly one documented behavior, and every "not working" moment comes from the same gap — nobody taught you the parts beyond git stash and git stash pop. Here are the four fixes that close it.

The most common reason: your new files survived the stash

git stash only stashes two things: changes you've staged, and changes to files Git already tracks. Everything else — new files, ignored files — stays exactly where it was.

The classic failure: you create a new component, modify the existing files, stash, switch branches, and your new component follows you into the other branch. You stare at git stash list like it betrayed you. It didn't. Untracked files were never in the deal.

The fix is one flag:

git stash -u   # or --include-untracked

Use -a (or --all) if you also want ignored files — but think twice before doing that in a big repo, because -a sweeps up your node_modules, build artifacts, and anything else .gitignore hides. On a large monorepo that's a very slow, very heavy stash.

One quirk worth knowing: untracked files are stored as a third parent commit on the stash entry. That means git stash show won't display them — the summary only covers tracked changes. To actually see what you stashed as untracked, run:

git show stash@{0}^3

If you ever diff a stash and something is missing, check the third parent before assuming you lost it.

stash pop blew up with a conflict — your work is still safe

The second panic moment: git stash pop dies with CONFLICT (content): merge conflict in .... The instinct is that you just destroyed something. You didn't.

Here's the safety rule: if pop hits conflicts, Git keeps the stash entry. The entry is only dropped when the apply succeeds cleanly. So when you see the conflict, the work is in two places — the conflicted working tree and the original stash entry — and you can take your time.

Fix the conflicts the same way you fix any merge: edit the markers, test, git add the resolved files, then git stash drop to clean up the now-applied entry.

One exception: --index. git stash pop --index tries to restore your staged/unstaged split exactly, and if there are conflicts, the whole operation fails instead of partially applying. That's by design — half-restoring your index would be worse. If you're using --index and hit conflicts, resolve them from the working tree side instead.

The cleanest escape hatch when a pop goes wrong is to stop trying to force it onto the current branch:

git stash branch <new-branch-name> [stash@{n}]

This creates a new branch at the commit the stash was originally made from, checks it out, applies the stash, and drops the entry — all in one move. Applying onto the original commit is where conflicts are least likely, because that's the tree the stash was diffed against.

The stash you can't find, the stash you named wrong, the stash you cleared

Every unnamed stash shows up as WIP on main: 5002d47 ... — and three of those in a row are indistinguishable. Name your stashes:

git stash push -m "halfway through checkout refactor"

(The old git stash save "message" syntax still works, but push is the documented form.)

Before popping anything, look at what you're about to apply: git stash show -p stash@{1} gives you the full diff. Pop targets the latest entry by default, but you can name any entry explicitly — git stash pop stash@{1} — keeping in mind that the indexes renumber after every pop. That's exactly why messages matter: stash@{2} means nothing, but a message tells you which work it is.

And if the worst already happened — git stash drop on the wrong entry, or even git stash clear — know that "permanent" is relative. The stash was a real commit, and it stays in the repository until garbage collection removes unreachable objects. git fsck --unreachable can surface it, and the refs/stash reflog (default 90-day expiry) often holds the commit hash. Don't clear a stash you're not sure about, but if you already did, there are recovery paths.

The parts nobody shows you: partial stashes, kept indexes, and paths

git stash isn't all-or-nothing. Three options cover most of the "I wish stash could..." cases:

• git stash -p — interactive hunk selection. It walks you through your changes piece by piece (y to stash a hunk, n to skip, s to split, q to finish). Perfect for the "I want to stash the fix but keep the debug prints" situation.
• git stash -k / --keep-index — stashes everything except what's staged. Handy for "commit the finished part now, keep experimenting with the rest."
• git stash push -- path/to/file — stash only specific paths. Combined with --staged / -S (stash only staged changes), you get precise control over what leaves the working tree.

The mental model that makes all of this click: a stash is a stack of commits Git builds from your working tree, your index, and optionally your untracked files — and every operation on it (pop, apply, branch) is just a merge against a commit you choose. Once you see it that way, the "not working" cases stop feeling like bugs and start looking like the defaults doing exactly what the documentation says they do.

Quick cheat sheet for your terminal: git stash -u -m "message" for the everyday stash (untracked included), git stash show -p before you pop, and git stash branch when the pop goes sideways.

Related reading: Git 3.0 Is Coming With SHA-256 — what changes for your daily workflow.

Related reading

Git keeps changing under your feet: Git 3 making SHA-256 the default is the next migration to prepare for. And when a stash fix lands in a pull request, small diffs and fast reviews keep it from rotting in the queue.

References

• git-stash — official Git documentation
• Git Stash — Atlassian Git Tutorial
• Git Stash: More Than Just Removing Unwanted Changes — Amarjit Kaur (Medium, Nov 2025)