Stash: Shelving Work in Progress

In one line

git stash temporarily shelves your uncommitted changes, giving you a clean working directory to switch contexts, and lets you bring them back exactly as they were whenever you're ready.

0/5 · 0%

Think of it like this

Quickly clearing your desk into a drawer to deal with an urgent interruption, fully intending to take everything back out and continue exactly where you left off once it's handled. git stash is exactly this for uncommitted Git changes — a temporary, recoverable shelf, not a commit and not a loss.

Key ideas

01
git stash (or git stash push) takes every uncommitted change in your working directory and staging area, saves them onto a STASH STACK, and resets your working directory back to a clean state matching the last commit — genuinely useful when you need to urgently switch branches (a critical bug report, say) but aren't ready to commit your current, half-finished work.
02
git stash list shows every stashed entry, most recent first (stash@{0}, stash@{1}, ...) — you can accumulate several stashes at once, though in practice most people stash, do something else, and immediately restore, rather than building up a genuine backlog.
03
git stash pop restores the MOST RECENT stash's changes back into your working directory AND removes it from the stash stack — the standard 'I'm done with the interruption, give me my work back' command. git stash apply does the same restoration but LEAVES the stash on the stack (useful if you want to apply the same stashed changes to more than one branch).
04
git stash push -m "a description" attaches a message to a stash — genuinely useful once you have more than one stash active at a time, since git stash list otherwise shows only a generic, hard-to-distinguish description for each entry.
05
git stash can conflict on pop/apply, exactly like a merge, if the working directory has changed enough since the stash was created that the stashed changes no longer apply cleanly — resolved with the same conflict-marker process as any other Git conflict (Phase 2.2), after which git stash drop removes the now-resolved stash entry manually.

Code & diagrams

stash.shmarkdown

The interrupt-and-resume workflow, start to finish.

cd ~/scratch/my-first-repo

# Mid-feature, uncommitted, messy state
echo "half-finished work" >> feature.txt
git status
# feature.txt shows as modified, not staged or committed

# Urgent interruption — shelve it and get a clean working directory
git stash push -m "WIP: half-finished feature work"
git status
# clean — as if the change never happened

# Go handle the urgent thing on a different branch
git switch main
# ... investigate, fix, whatever was needed ...
git switch feature/my-branch

# Bring your shelved work back exactly as it was
git stash list
# stash@{0}: On feature/my-branch: WIP: half-finished feature work

git stash pop
git status
# feature.txt is modified again, exactly as you left it — and the stash is gone

# If you wanted to keep the stash for reuse elsewhere instead:
# git stash apply    (restores it, but leaves it on the stack)
# git stash drop      (manually removes a stash you're done with)

Explain it without notes

What's the practical difference between git stash pop and git stash apply?

Why is stashing usually better than making a quick, half-finished commit just to switch branches temporarily?

Practice

Make an uncommitted change, stash it, switch to a different branch and back, then pop the stash and confirm your change is restored exactly as it was.

Create two separate stashes with descriptive messages using -m, and use git stash list to confirm you can tell them apart and identify which is which.

Trade-offs

↔
Stash is fast and convenient for short interruptions, but it's easy to forget about a stash entry entirely once you've moved on — a growing, forgotten stash list is a genuinely common source of 'wait, what was this for' confusion months later, which is exactly why descriptive messages (-m) and periodically running git stash list to clear out anything no longer needed are worth the small extra habit.

Done when you can

I can stash uncommitted changes, switch context, and restore them with pop.
I understand the difference between stash pop (removes) and stash apply (keeps on the stack).
I use descriptive stash messages once I have more than one active at a time.