Git Stash Explained: Save Work Without Committing

Quick Answer

git stash saves your uncommitted changes to a temporary shelf and gives you a clean working directory, without making a commit. You can then switch branches, pull updates, or fix something urgent, and run git stash pop to bring your work back. Use git stash list to see what you saved, and git stash push -m "note" to name a stash so you remember what is inside it.

What is git stash?

You are halfway through editing a file. The code does not compile yet, the feature is not done, so committing feels wrong. Then your teammate messages: "Can you quickly fix the login bug on main?" Now what? You do not want to lose your half-finished work, and you do not want to make an ugly "WIP" commit either.

This is exactly what git stash is for. It takes all your uncommitted changes, tucks them away on a temporary shelf, and gives you back a clean working directory, as if you had never started. Later, you run one command and your changes come right back. Nothing is committed and nothing is lost.

Think of it like closing a book with a bookmark inside. You put the book down to do something else, and when you pick it up again, you open straight to the page you were on. In this guide we will walk through saving, listing, restoring, naming, and cleaning up stashes, using real situations you will hit as a beginner.

Saving your work with git stash

First, check what you have changed. Run:

git status

Say it shows a modified file. To shelve everything at once, run:

git stash

Git responds with something like:

Saved working directory and index state WIP on main: 3f8a1c2 Add navbar

Now run git status again and you will see a clean tree, "nothing to commit, working tree clean". Your changes are not gone; they are safely parked. By default git stash captures two things:

• Files you have modified (changes to files Git already tracks).
• Changes you have staged with git add.

One important gotcha up front: plain git stash does not save brand-new files that Git has never seen (untracked files). We will fix that later with a flag. For now, just remember: stash is great for edits to existing files, and needs a nudge for new ones.

The real scenario: switching branches mid-task

Here is the classic case where stash saves the day. You are on a feature branch with unfinished edits, and you need to jump to main to fix an urgent bug.

If you just try to switch, sometimes Git carries your changes along quietly (which can be confusing), and sometimes it flatly refuses:

git switch main
error: Your local changes to the following files would be
overwritten by checkout: src/login.js
Please commit your changes or stash them before you switch branches.

Git blocks the switch because your edits clash with the version of that file on the other branch. The clean fix is exactly what the message suggests, stash first:

git stash
git switch main
# fix the urgent bug, commit it, push it
git switch feature
git stash pop

After git stash pop, your half-finished work reappears on the feature branch and you carry on as if nothing happened. This works even when Git would have let you switch anyway, and it is a safer habit, because you always start the other branch from a genuinely clean state. If you are still shaky on branches and switching, our free Git course walks through the whole workflow step by step.

Listing, applying, and popping stashes

You can stash more than once. Every stash gets pushed onto a stack, so the newest sits on top. To see them all, run:

git stash list

You get output like:

stash@{0}: WIP on feature: 9a2f1b0 Add form
stash@{1}: WIP on main: 3f8a1c2 Add navbar

Here stash@{0} is the most recent one. To bring a stash back, you have two commands:

• git stash apply restores the changes but keeps the stash on the list.
• git stash pop restores the changes and removes the stash from the list.

With no argument, both act on the newest stash, stash@{0}. To target a specific one, name it:

git stash apply stash@{1}
git stash pop stash@{1}

Use apply when you might want to reuse the same stash on more than one branch. Use pop for the normal "put it back and move on" case. If a pop hits a merge conflict, Git keeps the stash instead of deleting it, so you do not lose anything while you sort out the conflict.

Naming stashes with push -m

Those default WIP on feature labels are useless once you have three or four stashes. Which one had the payment fix? The modern, recommended command lets you add your own label:

git stash push -m "half-done payment validation"

Now git stash list reads clearly:

stash@{0}: On feature: half-done payment validation

You may see older tutorials use git stash save "message". That command still works but is deprecated, so prefer git stash push -m in new habits. The push form is also more flexible; for example, you can stash only specific files by listing them at the end:

git stash push -m "just the css tweaks" src/style.css

Before you restore a stash, you can peek inside it without applying anything:

git stash show -p stash@{0}

The -p flag prints the full diff, so you can confirm you are restoring the right work before you commit to it.

Stashing untracked and ignored files

Remember the earlier warning: plain git stash skips new files Git has never tracked. So if you just created src/newFeature.js and run git stash, that file stays sitting in your folder while everything else gets shelved. That surprises a lot of beginners.

To include untracked files, add the -u flag (short for --include-untracked):

git stash -u

Or combine it with a name:

git stash push -u -m "new feature file plus edits"

There is also git stash -a (--all), which goes one step further and stashes files ignored by .gitignore too. Be careful with -a: it will sweep up things like node_modules or build folders, which you almost never want. In everyday work, -u is the flag you actually reach for; -a is a rare, deliberate choice.

Rule of thumb: if you created new files and want them shelved with the rest, use git stash -u. Otherwise those files will get left behind.

Cleaning up: drop and clear

Stashes do not expire on their own. A messy stash list is confusing and can lead you to restore the wrong thing, so clean up once a stash has served its purpose.

To delete one specific stash without applying it:

git stash drop stash@{1}

To wipe the entire stash list in one go:

git stash clear

Be careful: clear deletes every stash with no confirmation prompt. There is no Recycle Bin for it in normal use. If you drop or clear a stash you actually needed, do not panic immediately, Git often keeps the underlying data around for a while, and you can sometimes recover it:

git fsck --no-reflog | grep commit

Then git stash apply <the-commit-hash> on a promising result. This is a last-resort rescue, not something to rely on, so treat clear and drop with respect.

Quick reference and recommendation

Here is the whole workflow in one place:

Our recommendation: use git stash for short, temporary detours, like fixing an urgent bug on another branch or pulling in updates. Always name your stashes with push -m, add -u when you have new files, and pop them back the same day. Stash is not long-term storage; if work will sit for days, make a proper commit on a branch instead. Kept short and tidy, git stash becomes one of the most reassuring tools in your daily Git routine.

Frequently Asked Questions