Git Stashing: Save and Restore Work-in-Progress Without Losing Your Mind

Every developer has been there: you're deep in a refactor, half the files are a mess, and suddenly a production bug demands an immediate hotfix. Commit the half-baked work? That's a crime scene in your history. Delete it? You'll lose hours. The old hack was copying files to /tmp or creating WIP commits with messages like 'DO NOT DEPLOY'. Both are terrible. Git stash solves this cleanly — it shelves your changes without a commit, letting you switch branches freely. By the end of this article, you'll know exactly when to stash, when to commit, and how to avoid the three gotchas that have burned me in production.

Why Stash Exists: The Problem of Uncommitted Context Switches

Git is built around commits. But not every piece of work is ready to commit. Maybe you're in the middle of debugging with print statements everywhere. Maybe you've staged a partial fix but the full fix isn't done. Committing that mess pollutes your history and breaks git bisect. Before stash, teams used workarounds: temporary branches, manual file copies, or the dreaded 'WIP' commit. All of them add friction. Stash gives you a lightweight, stack-based way to save state without touching your commit history. It's not a replacement for branches — it's a temporary holding pen for when you need to context-switch fast.

// io.thecodeforge — DevOps tutorial

# Start with a dirty working directory
echo "debug statement" >> app.py
git add app.py
echo "another change" >> utils.py

# Save everything to stash
git stash
# Output: Saved working directory and index state WIP on main: abc1234 Last commit

# Working directory is now clean — switch branches safely
git checkout hotfix
# Do the hotfix, commit, push

# Return to original branch
git checkout main

# Restore the stashed changes
git stash pop
# Output: Dropped refs/stash@{0} (abc1234...)

# Now app.py and utils.py have your changes back

Stash Stack: Managing Multiple Shelved Contexts

Stash is a stack (LIFO). Each stash is stored as stash@{n}. You can have multiple stashes active simultaneously — useful when you're juggling several half-finished features. But here's the trap: the stack grows fast, and without naming, you'll forget what each one contains. Always stash with a message. Use git stash list to see the stack. git stash show stash@{n} shows the files changed. git stash show -p stash@{n} shows the full diff. Never apply a stash blindly — inspect it first.

// io.thecodeforge — DevOps tutorial

# Create multiple stashes with messages
git stash push -m "WIP: refactor auth module"
git stash push -m "WIP: fix payment bug"
git stash push -m "WIP: add logging"

# List all stashes
git stash list
# Output:
# stash@{0}: On main: WIP: add logging
# stash@{1}: On main: WIP: fix payment bug
# stash@{2}: On main: WIP: refactor auth module

# Inspect a specific stash
git stash show stash@{1}
# Output: payment.py | 10 +++++-----

# Apply without dropping (safe for inspection)
git stash apply stash@{1}
# Then verify, then drop manually
git stash drop stash@{1}

Stashing Untracked and Ignored Files: The -u and -a Flags

By default, git stash only stashes tracked files (modified and staged). Untracked files (new files not yet added) are left behind. This is the #1 cause of 'lost' work after a stash. If you have new files you want to stash, use git stash -u (or --include-untracked). If you also want to stash ignored files (like .env or build artifacts), use git stash -a (or --all). Warning: -a can stash huge directories like node_modules — use with extreme caution. I've seen a stash balloon to 2GB because someone included -a in a monorepo.

// io.thecodeforge — DevOps tutorial

# Create a new untracked file
echo "new config" > new_config.yaml

# Stash only tracked changes — new_config.yaml stays
git stash
# Output: Saved working directory and index state WIP on main: ...
# new_config.yaml is still present!

# Stash including untracked files
git stash -u
# Output: Saved working directory and index state WIP on main: ...
# new_config.yaml is now stashed

# To restore, same commands work
git stash pop

# For ignored files (e.g., .env)
git stash -a
# Warning: this stashes everything in .gitignore too

Partial Stash: Stashing Only Specific Files or Hunks

Sometimes you don't want to stash everything. Maybe you have debug prints in one file and a real fix in another. git stash -p lets you interactively select hunks to stash, similar to git add -p. This is a lifesaver when you're deep in a debugging session and need to stash only the noise. Alternatively, you can stash a single file by using git stash push -m "msg" -- <file>. This stashes only the changes to that file, leaving everything else dirty.

// io.thecodeforge — DevOps tutorial

# Stash only changes in one file
echo "debug1" >> app.py
echo "real fix" >> payment.py

# Stash only payment.py
git stash push -m "partial: payment fix" -- payment.py
# app.py changes remain in working directory

# Interactive hunk selection
git stash -p
# Git shows each hunk and asks: (1/2) Stash this hunk [y,n,q,a,d,/,e,?]?
# Answer y for hunks you want to stash, n to leave

# After partial stash, remaining changes are still dirty
git status
# Shows app.py as modified

Stash to Branch: Recovering from a Messy Stash

The most powerful stash command is git stash branch <branchname>. It creates a new branch from the commit where the stash was created, then applies the stash. This is the escape hatch when a stash won't apply cleanly to the current branch because the code has diverged too much. It's also the safest way to turn a stash into a proper branch for review. I use this constantly when I realize a stash should have been a feature branch all along.

// io.thecodeforge — DevOps tutorial

# Suppose you have a stash that conflicts on current main
git stash list
# stash@{0}: On main: WIP: refactor auth

# Create a new branch from the stash's original commit
git stash branch refactor-auth stash@{0}
# Output: Switched to a new branch 'refactor-auth'
#         On branch refactor-auth
#         Changes not staged for commit:
#           modified:   auth.py
#         Dropped stash@{0} (abc1234...)

# Now you're on a clean branch with the changes applied
# No conflicts! Commit normally and push.
git add auth.py
git commit -m "refactor auth module"

When Not to Stash: The Case for Commits and Branches

Stash is a temporary tool. If your work will take more than a few hours, or if you need to collaborate on it, create a branch and commit. Stashes are local — they don't push to remotes. If your laptop dies, your stashes die with it. Also, stashes don't have a reflog (the stash itself is stored in .git/refs/stash but the individual entries are not in the reflog). Once dropped, recovery is painful. For work that's more than a quick context switch, use a feature branch with WIP commits that you'll squash later. Stash is for emergencies, not project management.

// io.thecodeforge — DevOps tutorial

# Bad: using stash for long-term work
git stash push -m "big feature"
# ... days later ...
git stash list  # still there, but risky

# Good: use a branch with WIP commits
git checkout -b feature/big-feature
git add .
git commit -m "WIP: partial feature"
# Push to remote for backup
git push origin feature/big-feature
# Later, squash before merging to main