Stash

## What a stash is for You are halfway through a change when something urgent arrives: a hotfix, a branch to review, a colleague's bug. `git stash push` (or the bare `git stash`) records your uncommitted work, then resets the working tree and index back to `HEAD`, leaving you clean. Later you restore it. By default a stash covers **tracked** files: modifications to tracked files in the working tree and staged changes in the index. Untracked and ignored files are left alone unless you ask for them explicitly. ## The two restore verbs ``` git stash list stash@{0}: WIP on feature: 9a3f21c Add parser skeleton stash@{1}: WIP on main: 47bd0e1 Bump version git stash apply # restore stash@{0}, keep the entry git stash pop # restore stash@{0}, then drop it ``` Both default to the most recent entry, `stash@{0}`, and both accept an explicit one: `git stash apply stash@{2}`. The only difference is the cleanup. `pop` is `apply` followed by `drop`. That is a real convenience — an unpopped stash list is how stashes accumulate for months until nobody knows what is in them — but it means an entry disappears once the restore looks successful. ## When to prefer `apply` - You want the same changes on **more than one** branch: apply, then apply again elsewhere. - You are not sure this is the right branch to restore onto and want a trivial undo: discard the working tree and apply again. - You are restoring an old entry and want the list untouched while you check what came back. The cost is a stash list that grows; clean it with `git stash drop stash@{n}` for one entry, or `git stash clear` for all of them. `clear` is unforgiving — it discards every entry at once. ## Staging is not preserved by default A point interviewers like: restoring does **not** rebuild your index. Everything the stash contained comes back as unstaged working-tree changes, even the parts that were staged when you stashed. If you want the original staged/unstaged split back, pass `--index`: ``` git stash pop --index ``` That can fail where the plain form would succeed, because Git has to reproduce a specific index state as well as the file contents. ## Conflicts and why pop is safer than it looks Restoring is a merge, not a file copy, so it can conflict if the branch moved since you stashed. On conflict, Git writes conflict markers into the affected files and — crucially — **keeps** the stash entry. `pop` only drops after a clean application. So a conflicted pop leaves you with work to resolve *and* the original stash still in the list; after resolving you drop it yourself. ## Addressing entries `stash@{0}`, `stash@{1}` and so on are positions in the stash list, not stable names. Push a new stash and everything shifts down by one. Inspect before you act: ``` git stash list git stash show stash@{1} # summary of changed files git stash show -p stash@{1} # full patch ``` Giving stashes messages when you create them (`git stash push -m "parser wip"`) turns an unreadable list of `WIP on branch:` lines into something you can navigate weeks later. ## Common mistakes - Assuming `pop` restores staging. It does not, unless you pass `--index`. - Assuming `pop` always removes the entry. A conflict keeps it. - Treating the stash as long-term storage. It is a shelf, not a branch — entries carry no branch name in their identity and become impossible to interpret after a few weeks. If work matters, commit it on a branch. - Running `git stash clear` to "clean up" without checking what is in the list. ## What a good answer sounds like "`pop` is `apply` plus `drop`. Use `apply` when you might need the stash again or are unsure about the target branch; use `pop` for the normal restore. Neither restores the index unless you pass `--index`, and a conflicting `pop` keeps the entry so nothing is lost."