Git Stash: Untracked Files Follow Branches – CI Failures
- git stash push -m 'description' — always add a message. Unnamed stashes become mystery boxes within 24 hours.
- Use git stash -u to include untracked files; without it, new files stay in your working directory when you switch branches.
- Prefer git stash apply over pop when conflicts are possible — pop deletes the stash before you resolve conflicts, leaving you with no backup.
- git stash push -m 'description': saves tracked changes with a label
- git stash -u: includes untracked files (new files not yet git add'd)
- git stash pop: restores and removes from stack — use when confident no conflicts
- git stash apply: restores but keeps in stack — use when conflicts are possible
Git Stash Triage Cheat Sheet
Stash pop hit a merge conflict — stash is gone from the stack
git reflog | grep stash (find the stash application entry)git fsck --no-reflogs | grep dangling (find dangling commit objects)Stashed changes on wrong branch — working directory has wrong files
git reset --hard HEAD (undo the stash application)git checkout <correct-branch> (switch to where you need the stash)Cannot find which stash has my changes
git stash list (read messages — this is why you always use -m)git stash show -p stash@{N} | grep 'search-term' (search each stash diff)Untracked files ended up on the wrong branch after stash + switch
git log --oneline -3 (find the commit with the wrong files)git revert <commit-hash> (undo the commit on the wrong branch)git stash clear ran accidentally — all stashes gone
git fsck --no-reflogs | grep dangling (find lost stash commits)git stash apply <hash> (recover each stash commit)Production Incident
git stash to save their work — but stash only saves tracked files by default.
3. PaymentRetryService.java was untracked, so it was NOT stashed. It remained in the working directory.
4. Developer switched to main: git checkout main.
5. PaymentRetryService.java (the untracked file) followed them to main.
6. During the hotfix, they ran git add . which staged everything — including PaymentRetryService.java.
7. The file was committed to main with incomplete, non-compiling feature code.
8. CI built from main and failed on the compilation error.git revert <hotfix-commit-hash>.
2. The developer switched back to feature/payment-retry and stashed correctly: git stash push -u -m 'WIP: PaymentRetryService'.
3. Team rule: always use git stash push -u when stashing with untracked files.
4. Team rule: never run git add . on main — always add files individually or use git add -p.
5. Added pre-commit hook to warn when new files are staged on main that do not exist on the previous commit.Production Debug GuideSystematic recovery paths for lost stashes, wrong-branch pops, and stash conflicts.
git reflog — find the stash application entry.
3. The stash commit object still exists: git fsck --no-reflogs | grep dangling — find dangling commit objects.
4. Recover: git stash apply <hash> using a hash that looks like your stash.
5. Prevention: use git stash apply when conflicts are possible. Then git stash drop manually after resolving.git reset --hard HEAD to restore the branch to its pre-pop state.
3. Switch to the correct branch: git checkout <correct-branch>.
4. Apply there: git stash apply stash@{0} (the stash is still in the stack if you used apply, or recover via reflog if you used pop).git stash list — read the messages (this is why you always use -m).
2. If messages are unhelpful: git stash show -p stash@{0} — full diff of each stash.
3. Search stashes for a specific change: git stash show -p stash@{N} | grep 'search-term' for each N.
4. Or: git log --all --oneline --grep='search-term' — stash entries appear in the log.git log --oneline -3 — find the commit that includes the wrong files.
3. Revert: git revert <commit-hash> to undo the commit on the wrong branch.
4. Switch to correct branch: git checkout <correct-branch>.
5. Stash correctly: git stash push -u -m 'WIP: new files' to include untracked files.git fsck --no-reflogs | grep dangling — find dangling commit objects.
3. Each stash entry is a commit internally. Filter by date: look for commits created around the time you stashed.
4. Apply: git stash apply <hash> for each recovered stash commit.
5. Prevention: never run git stash clear without checking git stash list first.git stash shelves uncommitted working directory and index changes into a stack. It is the standard tool for context switching — you stash your current work, switch to a hotfix branch, then unstash when you return. The core failure mode: stash pop deletes the stash even on merge conflicts, leaving you with no backup. Use apply + manual drop when conflicts are possible.
The second failure mode: stash does not include untracked files by default. New files you have not git add'd remain in the working directory when you switch branches. They get committed to the wrong branch. Use stash -u to include them.
Stashes are global to the repository, not scoped to a branch. You can pop a stash made on feature/x onto main. This is sometimes intentional and sometimes a very bad day. Always use stash push -m 'description' to label your stashes — unnamed stashes become mystery boxes within 24 hours.
Basic Stash: Save and Restore Work
The core workflow is three commands. git stash shelves everything in your working directory and index that differs from HEAD. git stash pop restores the most recent stash and removes it from the stack. git stash apply restores without removing — useful when you want to apply the same stash to multiple branches.
One thing that surprises developers coming from other VCS systems: git stash by default only stashes tracked files. If you created a new file that hasn't been git add-ed yet, it won't be stashed. It'll sit there in your working directory when you switch branches, which can lead to unintended commits on the wrong branch. Use git stash -u (or --include-untracked) to include new files.
The stash is a stack — each git stash pushes a new entry. git stash pop pops the top (most recent). This is correct behaviour for the common case but becomes confusion when you stash, do some more work, stash again, and then try to figure out which stash has what.
# io.thecodeforge — Git Stash Basics # ───────────────────────────────────────────────────────────── # Save current work to stash (tracked files only) # ───────────────────────────────────────────────────────────── git stash # Save with a descriptive message — always do this git stash push -m "WIP: payment retry exponential backoff" # Include untracked files (new files not yet git add'd) git stash push -u -m "WIP: new PaymentRetryService class" # ───────────────────────────────────────────────────────────── # Restore most recent stash AND remove it from the stack # ───────────────────────────────────────────────────────────── git stash pop # Restore most recent stash but KEEP it in the stack git stash apply # ───────────────────────────────────────────────────────────── # List all stashes # ───────────────────────────────────────────────────────────── git stash list # Output: # stash@{0}: On feature/payment-retry: WIP: payment retry exponential backoff # stash@{1}: On main: WIP: hotfix debug logging # ───────────────────────────────────────────────────────────── # Restore a specific stash by index # ───────────────────────────────────────────────────────────── git stash pop stash@{1} git stash apply stash@{1} # ───────────────────────────────────────────────────────────── # See what's in a stash before applying # ───────────────────────────────────────────────────────────── git stash show stash@{0} git stash show -p stash@{0} # Full diff
# git stash list:
stash@{0}: On feature/payment-retry: WIP: payment retry exponential backoff
stash@{1}: On main: WIP: hotfix debug logging
# git stash show stash@{0}:
src/main/java/io/thecodeforge/payment/PaymentRetryService.java | 47 +++++++++
1 file changed, 47 insertions(+)
- Stash is a stack — push adds, pop removes the top
- Stashes are global — not attached to any branch
- You can pop a stash made on feature/x onto main (or any branch)
- This flexibility is powerful but dangerous — always check which branch you are on before popping
Stash Pop vs Apply: When to Use Each
The difference matters more than most tutorials let on.
git stash pop = apply + delete from stack. Use this 95% of the time. The moment you successfully restore your work, the stash entry is gone. Clean, no accumulation.
git stash apply = apply but leave in stack. Use this when: you want to apply the same changes to multiple branches (e.g. a config change you need on both a feature branch and a hotfix branch), or when you're not 100% sure the stash applies cleanly and you want to keep it as a backup while you verify.
There's one critical behaviour difference: if git stash pop encounters a conflict, it still removes the stash from the stack before throwing the conflict. You're now in a conflicted state with the stash gone. This is a Git footgun — you want git stash apply when there's any chance of conflicts, so the stash survives even if the apply fails.
# io.thecodeforge — Stash Pop vs Apply # ───────────────────────────────────────────────────────────── # Scenario: you might have conflicts — use apply, not pop # ───────────────────────────────────────────────────────────── git stash apply stash@{0} # If it applied cleanly with no conflicts, manually drop the stash git stash drop stash@{0} # If there ARE conflicts, resolve them, then drop manually # The stash is still in the stack — you haven't lost anything git status # Shows conflicted files # ... resolve conflicts ... git add . git stash drop stash@{0} # Now safe to remove # ───────────────────────────────────────────────────────────── # Apply same stash to two branches # ───────────────────────────────────────────────────────────── git checkout feature/branch-a git stash apply stash@{0} # Applied to branch A — stash still exists git checkout feature/branch-b git stash apply stash@{0} # Applied to branch B too git stash drop stash@{0} # Now clean up # ───────────────────────────────────────────────────────────── # Clear ALL stashes (nuclear — use with care) # ───────────────────────────────────────────────────────────── git stash clear
Auto-merging src/main/java/io/thecodeforge/payment/PaymentService.java
CONFLICT (content): Merge conflict in src/main/java/io/thecodeforge/payment/PaymentService.java
# Stash is still in stack — safe to resolve then drop
Stashing Partial Changes and Specific Files
Sometimes you only want to stash part of your changes — for example, you've been working on two unrelated things in the same branch (happens to everyone, don't judge) and you want to commit one thing cleanly before stashing the other.
git stash push -- <path> stashes only the specified files. Everything else stays in your working directory.
git stash push -p (patch mode) drops you into an interactive hunk-by-hunk selection — exactly like git add -p. You choose yes/no for each chunk. This is powerful but slow for large changesets.
# io.thecodeforge — Stashing Partial Changes and Specific Files # ───────────────────────────────────────────────────────────── # Stash only specific files # ───────────────────────────────────────────────────────────── git stash push -m "WIP: retry config" -- src/main/java/io/thecodeforge/payment/RetryConfig.java # Stash multiple specific files git stash push -m "WIP: two related files" \ -- src/main/java/io/thecodeforge/payment/RetryConfig.java \ -- src/main/java/io/thecodeforge/payment/RetryPolicy.java # ───────────────────────────────────────────────────────────── # Interactive patch mode — choose which hunks to stash # ───────────────────────────────────────────────────────────── git stash push -p -m "WIP: partial changes" # Git shows each change hunk and asks: stash this hunk? [y/n/q/a/d/?] # ───────────────────────────────────────────────────────────── # Create a branch from a stash (useful for long-lived stashes) # ───────────────────────────────────────────────────────────── git stash branch feature/retry-config stash@{0} # Creates new branch at the commit where you stashed, applies the stash, drops it
# Only RetryConfig.java was stashed
# RetryPolicy.java remains in working directory
- git stash branch <name> <stash>: creates branch at stash point, applies stash, drops it
- Use when a stash has been sitting for days and has become important work
- Branches are visible in git branch -a. Stashes are only visible in git stash list.
- If a stash survives for weeks, it should have been a branch from the start.
| Command | Effect | Stash Removed? | Best For |
|---|---|---|---|
| git stash | Stash tracked files | N/A | Quick context switch |
| git stash -u | Stash tracked + untracked | N/A | When you have new files |
| git stash pop | Apply + remove from stack | Yes | Normal restore — 95% of cases |
| git stash apply | Apply, keep in stack | No | Risky merges or multi-branch apply |
| git stash drop | Remove without applying | Yes | Discard stash you no longer need |
| git stash clear | Remove ALL stashes | Yes (all) | Spring cleaning — careful |
| git stash branch <name> | Create branch from stash | Yes | Long-lived stashes that deserve a branch |
🎯 Key Takeaways
- git stash push -m 'description' — always add a message. Unnamed stashes become mystery boxes within 24 hours.
- Use git stash -u to include untracked files; without it, new files stay in your working directory when you switch branches.
- Prefer git stash apply over pop when conflicts are possible — pop deletes the stash before you resolve conflicts, leaving you with no backup.
- git stash branch <name> <stash> converts an old stash into a proper branch — the right move when a stash has grown into more work than you expected.
- Stashes are global to the repo, not scoped to a branch — applying a stash on the wrong branch is an easy mistake with sometimes messy consequences.
- Stashes are commits internally — recoverable via git fsck --no-reflogs | grep dangling even after deletion. But do not rely on this as a primary safety net.
⚠ Common Mistakes to Avoid
Interview Questions on This Topic
- QWhen would you use git stash apply instead of git stash pop?
- QA developer stashed changes, switched branches, and now can't find which stash contains their work. How do they find and apply the right one?
- QExplain how git stash stores its data internally. Is a stash a commit?
- QYou have three stashes and want to apply the second one without disturbing the others. What command do you run?
- QA developer ran git stash pop and hit a merge conflict. The stash is gone from git stash list. How do they recover it?
- QA developer stashed without -u, switched to main, and untracked files were committed to main. Explain what happened and how to fix it.
Frequently Asked Questions
What is the difference between git stash pop and git stash apply?
git stash pop applies the stash and immediately removes it from the stash stack. git stash apply applies it but leaves it in the stack. Use apply when there's a chance of merge conflicts (so the stash survives if the apply fails) or when you want to apply the same stash to multiple branches.
Does git stash save untracked files?
No, by default git stash only saves tracked files that have been modified. To include untracked files (new files not yet added with git add), use git stash push -u or git stash push --include-untracked.
How do I see what's in a stash before applying it?
Run git stash show stash@{N} for a summary of changed files, or git stash show -p stash@{N} for the full diff. Replace N with the stash index from git stash list.
Can I recover a stash I accidentally dropped?
Sometimes. Run git fsck --no-reflogs | grep commit to find dangling commit objects (stash entries are commits internally). You can then run git stash apply <hash> on any hash that looks like your lost stash. This works within the gc.reflogExpire window (default 30 days) as long as you haven't run git gc.
How do I recover a stash after git stash pop hit a merge conflict?
git stash pop deletes the stash from the stack even on conflict. The stash commit still exists in the object store. Run git fsck --no-reflogs | grep dangling to find dangling commit objects. Apply with git stash apply <hash>. Prevention: use git stash apply instead of pop when conflicts are possible.
What happens to stashes after 90 days?
Stashes are garbage-collected after gc.reflogExpire (default 90 days). Once collected, they are gone permanently. If you need changes longer than a few days, convert the stash to a branch with git stash branch <name> <stash>.
Developer and founder of TheCodeForge. I built this site because I was tired of tutorials that explain what to type without explaining why it works. Every article here is written to make concepts actually click.