Git Stash
debt(d7/e3/b3/t7)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints note automated=no and the only signal is accumulation of unnamed stashes visible in git stash list — there is no automated lint or SAST tool that flags stash misuse. A developer or reviewer must manually inspect the stash list or notice lost work after a machine wipe.
Closest to 'simple parameterised fix' (e3). The quick_fix indicates adopting git stash push -m 'description', using --patch for partial stashing, and preferring short-lived branches. This is a small behavioral change and minor refactor of workflow habits rather than a single one-liner swap, but does not span multiple files or require architectural rework.
Closest to 'localised tax' (b3). Stash misuse is scoped to an individual developer's local workflow and the local .git directory. It does not impose a persistent tax on the broader codebase or other team members — though lost stashes can cause rework, the structural burden is contained to one developer's context at a time.
Closest to 'serious trap' (t7). The misconception field explicitly states developers treat stash as safe long-term storage, not realising stashes are local-only and not pushed to remote. Additionally, git stash pop silently drops the stash even on merge conflict (a behavior that contradicts how most 'apply and revert on failure' patterns work elsewhere), making this a serious cognitive trap that contradicts expected behavior.
Also Known As
TL;DR
Explanation
git stash push saves tracked changes (and optionally untracked with -u) to a stack. git stash pop restores the most recent stash and removes it. git stash apply restores without removing. git stash list shows all stashes with indices. git stash show -p stash@{n} shows the diff. Stashes are named with -m for clarity. A common mistake: stashing without a message makes stash@{3} meaningless two weeks later. Stash is useful for quick context switches but should not replace proper branching for long-lived work.
Diagram
flowchart LR
DIRTY[Working directory<br/>uncommitted changes] -->|git stash push -u -m name| STACK[(Stash stack)]
STACK -->|git stash pop| RESTORED[Changes restored<br/>stash removed]
STACK -->|git stash apply| APPLIED[Changes applied<br/>stash kept]
subgraph Commands
LIST[git stash list<br/>see all stashes]
SHOW[git stash show -p stash@0<br/>see diff]
DROP[git stash drop stash@0<br/>delete one]
CLEAR[git stash clear<br/>delete all]
end
subgraph When_to_Use
SWITCH[Need to switch branch quickly]
PULL[Need to pull before committing]
EXPERIMENT[Trying a different approach]
end
style STACK fill:#6e40c9,color:#fff
style RESTORED fill:#238636,color:#fff
Common Misconception
Why It Matters
Common Mistakes
- Stashing without a message — stash@{2} is meaningless; use git stash push -m 'WIP: payment refactor'.
- git stash pop when a merge conflict occurs — pop removes the stash even if the apply fails; use git stash apply then manually drop.
- Accumulating many stashes — more than 2-3 stashes signals a branching problem, not a stash use case.
- Not stashing untracked files — git stash push -u includes new untracked files that plain stash misses.
Code Examples
# Multiple unnamed stashes — impossible to identify:
git stash # stash@{0}
git stash # stash@{1} — what was this?
git stash # stash@{2} — no idea
git stash list
# stash@{0}: WIP on main: abc1234 fix typo
# stash@{1}: WIP on main: abc1234 fix typo
# stash@{2}: WIP on main: abc1234 fix typo# Named stashes + include untracked:
git stash push -u -m 'WIP: payment webhook handler'
git stash list
# stash@{0}: On feature/payments: WIP: payment webhook handler
# Apply without removing (safer for conflicts):
git stash apply stash@{0}
# Resolve any conflicts, then:
git stash drop stash@{0}