LiveChat 
Support 
Git Stash Pop: The Complete Guide to the Git Stash Workflow
You are three files deep into a feature, nothing is ready to commit, and a teammate pings you: production is broken, fix it now. You cannot commit half-finished work, and you cannot switch branches with a dirty working directory hanging over you. This is the exact moment `git stash` was built for, and `git stash pop` is how you get your work back when the fire is out.
Git stash temporarily shelves your uncommitted changes so you get a clean working directory, then lets you restore them later. It is the pressure-release valve of the Git stash workflow: stash now, deal with the urgent thing, pop your work back when you return. This guide walks through every command you need, with heavy code examples, and centers on the one distinction that trips up even experienced developers: `git stash pop` versus `git stash apply`.
Key Takeaways
• `git stash` shelves your uncommitted changes and gives you a clean working directory.
• `git stash pop` reapplies your most recent stash and deletes it from the stash list.
• `git stash apply` reapplies your stash but keeps it in the list as a backup.
• Use `git stash list` to see all stashes, referenced as `stash@{0}`, `stash@{1}`, and so on.
• The professional habit for risky restores: apply first, verify, then drop — never blindly `pop`.
This article is part of our hosting for developers pillar guide, which covers running real Git workflows in an environment you actually control.
What Does Git Stash Actually Do?
Git stash takes the modified tracked files in your working directory and your staging area, saves them onto a separate stack, and then reverts your working directory back to a clean `HEAD`. Your changes are not lost — they are parked on a stack you can reach at any time.
The basic save command is simply:
“`bash git stash “`
After running it, `git status` will report a clean tree, as if you had never started editing:
“`bash $ git status On branch feature/checkout nothing to commit, working tree clean “`
Under the hood, Git creates two (or three) commit-like objects to record your index and working tree state, then resets you to a clean state. The classic full form of the command is `git stash push`, and `git stash` on its own is just a convenient alias for it.
Why bother? Because Git refuses to let you switch branches or pull when local changes would be overwritten. Stashing clears the deck so you can move freely, then bring your work right back.
How Do You Save and Restore Changes with Git Stash?
The two commands you will use most are saving and restoring. Here is the minimal cycle:
“`bash
git stash
git stash pop “`
That is the core loop. `git stash pop` reapplies the most recent stash to your working directory and then removes it from the stash list in one step. It is a one-time restore: restore and forget.
If you want to see what you have shelved before restoring anything, list your stashes:
“`bash $ git stash list stash@{0}: WIP on feature/checkout: 9f2c1a4 add payment validation stash@{1}: WIP on main: 7b3e8d2 tweak header spacing “`
Each entry is addressed as `stash@{0}` (the newest), `stash@{1}` (the next), and so on. The numbers shift as you add and remove stashes, so always check `git stash list` before targeting a specific one.
What Is the Difference Between Git Stash Pop and Git Stash Apply?
This is the heart of the Git stash workflow, and it is where most mistakes happen.
“`bash
git stash pop
git stash apply “`
Both commands reapply your stashed changes to the working directory. The difference is what happens to the stash afterward:
| Command | Reapplies changes? | Keeps stash in list? |
|---|---|---|
| `git stash pop` | Yes | No — it is deleted |
| `git stash apply` | Yes | Yes — it stays |
`git stash apply` is the right choice when you might want to reapply the same changes to more than one branch, or when you want a safety net while you confirm the restore went cleanly. `git stash pop` is the convenient default when you are confident you want the changes back exactly once.
The pop-versus-apply distinction is git stash’s one real trap, and it matters more than it looks. `git stash pop` reapplies your stashed changes and deletes the stash from the list — a one-time restore. `git stash apply` reapplies them but keeps the stash saved. People reach for `pop` by habit, which is usually fine. But here is the gotcha: if popping causes a merge conflict, Git applies the changes but, in many cases, does not remove the stash — it leaves it so you do not lose your work. So people resolve the conflict, think they are done, and later discover the stash is still lurking in the list — or, conversely, they assume it is safe and clear it prematurely, losing the very changes they fought to preserve.
The safer professional habit, especially when you are not 100% sure the apply will be clean (switching across diverged branches, or restoring after a `pull`), is to use `git stash apply` first — reapply your work while keeping the stash as a safety net — confirm everything looks right, and only then `git stash drop` it deliberately:
“`bash git stash apply # reapply, but keep the stash as a backup
git stash drop # only now, deliberately remove it “`
`pop` is “restore and forget.” `apply` is “restore but keep a backup.” When the cost of losing those changes is high, choose apply-then-drop over `pop`, so a surprise conflict never strands you between a half-applied stash and a deleted one.
How Do You Manage Multiple Stashes?
You can stash as many times as you like; each new stash lands on top of the stack at `stash@{0}`, pushing the older ones down.
“`bash $ git stash list stash@{0}: WIP on feature/login: 3a9f1c2 … stash@{1}: WIP on feature/login: 8e2d4b7 … stash@{2}: WIP on main: 1c7a9f3 … “`
Anonymous stacks get confusing fast, so give your stashes a message when you save. Use the full `push` form with `-m`:
“`bash git stash push -m “half-finished payment form validation” “`
Now your list is readable:
“`bash $ git stash list stash@{0}: On feature/checkout: half-finished payment form validation stash@{1}: On main: tweak header spacing “`
To restore a specific stash rather than the most recent, pass its reference to `pop` or `apply`:
“`bash
git stash pop stash@{1}
git stash apply stash@{1} “`
You can also peek at what a stash contains before restoring it:
“`bash git stash show stash@{1} # summary of changed files git stash show -p stash@{1} # full patch / diff “`
How Do You Delete, Clear, and Include Untracked Files?
Restoring is only half the lifecycle. You also need to clean up stashes you no longer want.
“`bash
git stash drop stash@{0}
git stash clear “`
Be deliberate with `git stash clear` — it wipes the entire stash stack with no confirmation. There is no friendly undo, so reserve it for when you are certain everything on the stack is disposable.
One important gotcha: a plain `git stash` only shelves tracked files. Brand-new files that Git is not yet tracking are left behind in your working directory. To include untracked files, add `-u` (or `–include-untracked`):
“`bash
git stash -u
git stash -a # –all “`
This is a frequent surprise: developers stash, switch branches, and find their new files still sitting there because they were never tracked. When in doubt on a feature with new files, reach for `git stash -u`.
Here is a quick reference for the full command set:
| Command | What it does |
|---|---|
| `git stash` | Shelve tracked changes, clean the working directory |
| `git stash push -m “msg”` | Shelve changes with a descriptive message |
| `git stash -u` | Shelve changes including untracked files |
| `git stash list` | List all stashes (`stash@{0}`, `stash@{1}`, …) |
| `git stash show -p stash@{0}` | Show the diff of a stash |
| `git stash pop` | Reapply the newest stash and delete it |
| `git stash apply` | Reapply the newest stash but keep it |
| `git stash pop stash@{1}` | Reapply a specific stash and delete it |
| `git stash drop stash@{0}` | Delete a stash without applying it |
| `git stash clear` | Delete every stash on the stack |
What Does the Common Git Stash Workflow Look Like?
Here is the canonical real-world scenario — the urgent-fix interruption — start to finish:
“`bash
git status
git stash push -m “WIP: checkout refactor”
git checkout main git pull origin main
git add fix.js git commit -m “hotfix: correct tax rounding” git push origin main
git checkout feature/checkout
git stash pop “`
That six-step loop — work, stash, switch/pull, fix, switch back, pop — is the bread and butter of the Git stash workflow. For more on the branch-switching pieces around it, see the sibling guides on branching and checkout below.
How Do You Handle Conflicts When Popping a Stash?
If the branch you are restoring onto has changed since you stashed, reapplying may produce a merge conflict. This is normal and resolvable — you handle it exactly like any merge conflict.
“`bash $ git stash pop Auto-merging src/cart.js CONFLICT (content): Merge conflict in src/cart.js The stash entry is kept in case you need it again. “`
Notice that last line: when `pop` hits a conflict, Git typically keeps the stash rather than deleting it, so your work is not lost. To finish:
“`bash
git add src/cart.js
git status
git stash drop “`
This is precisely why the apply-then-drop habit is safer for risky restores: when you expect possible conflicts, run `git stash apply`, resolve, verify, and only then `git stash drop` — leaving no ambiguity about whether the stash is still on the stack.
Run Real Git Workflows on Infrastructure You Control
A stash stack only helps if you have a stable, capable place to develop. DarazHost VPS and dedicated servers give developers full Git over SSH — stash, branch, and manage your work in a real environment with guaranteed resources and 24/7 support. When your build pipeline, staging branch, and production deploy all live on hardware you control, the Git stash workflow becomes part of a clean, professional development loop rather than a workaround for a flaky shared host. It is the controllable home serious Git workflows need.
Frequently Asked Questions
Does `git stash pop` delete my stash? Yes. `git stash pop` reapplies the most recent stash and then removes it from the stash list. The exception is when reapplying causes a merge conflict — in that case Git usually keeps the stash so you do not lose your changes, and you must remove it later with `git stash drop`.
What is the difference between `git stash pop` and `git stash apply`? Both reapply your shelved changes to the working directory. `git stash pop` deletes the stash afterward (a one-time restore), while `git stash apply` keeps the stash in the list so you can reapply it again or hold it as a backup.
Why are my new files not stashed? A plain `git stash` only shelves tracked files. Untracked (brand-new) files are left in your working directory. Use `git stash -u` to include untracked files, or `git stash -a` to also include ignored files.
How do I restore a specific stash, not the latest one? Pass the stash reference: `git stash pop stash@{1}` to restore and remove it, or `git stash apply stash@{1}` to restore while keeping it. Run `git stash list` first to confirm the index, since the numbers shift as stashes are added and removed.
How do I delete a stash without applying it? Use `git stash drop stash@{0}` to remove a single stash, or `git stash clear` to wipe the entire stash stack at once. Be careful — `clear` has no easy undo.
