Git stash pop vs. apply: restore changes and control cleanup

Choose whether a restored stash stays in the list, handle conflicts, recover staged state, and reuse saved changes across branches.

Best practices
Illustration of Git history and collaboration

Both commands restore saved changes. git stash apply keeps the stash entry; git stash pop removes it after a successful application. If pop encounters conflicts, the entry stays in the list.

git stash apply                 # Restore the latest entry and keep it
git stash pop                   # Restore the latest entry; drop on success
git stash apply 'stash@{2}'      # Restore a particular entry and keep it

Use apply when you want to inspect the result before deciding whether to delete the saved copy, or when you intend to reuse the change elsewhere. Use pop when successful restoration should also remove the entry.

Result apply pop
Changes apply successfully Entry retained Entry removed
Changes conflict Entry retained Entry retained
Original staged state restored Request --index Request --index

Resolve conflicts before trying again

A failed application can leave both successfully applied changes and unresolved paths. Keeping the stash does not roll back the working directory.

git status
git diff

Resolve each conflict, stage the resolved files, and inspect the complete result. There is no git stash --continue step. Commit the work when appropriate. If you used pop, do not blindly run it again after resolving conflicts: the original entry is still present and would be applied again.

When the restored work is safely preserved, refresh git stash list and drop the intended entry explicitly:

git stash list
git stash drop 'stash@{0}'

The last command is appropriate only if that is still the entry you have finished with. Entry numbers change as the list changes.

Restore staged changes when needed

git stash apply --index 'stash@{0}'

--index attempts to restore both the working files and the saved index state. Without it, do not rely on the original staged/unstaged split being reproduced. Restored additions and pre-existing index state can leave some changes staged. Newer Git versions also support the stash.index configuration option; consult the manual for your installed version.

Reuse a stash on another branch

Start with a clean working tree. Apply the entry to the first branch, review it, and commit the intended changes before switching to the next branch. Applying alone leaves uncommitted work that might follow you to another branch or prevent the switch.

git switch branch-a
git stash apply 'stash@{0}'
# Review, stage the intended files, and commit them here.
# Only after the working tree is clean:
git switch branch-b
git stash apply 'stash@{0}'

Keep the entry until both results are checked. Different branch contents can produce different conflicts.

FAQ

What if I popped onto the wrong branch?

Inspect git status first. If the application succeeded, the working tree was clean beforehand, and there are no conflicts, you can stash the restored work again, switch branches, and apply it there. Include -u if it contains untracked files. If unrelated edits were already present, isolate and preserve them before attempting cleanup. An unmerged index must be resolved before you can create another stash.

How should I clean up old entries?

Inspect each entry, then use drop for the ones you no longer need. git stash clear removes the entire list. Dropped objects may temporarily remain in the repository, but recovery is uncertain and pruning can remove them permanently. Preserve important work as commits before clearing anything.

See the official stash reference for application, cleanup, and configuration details.

Get a tailored plan

Contact us

Join the community

Scan with WeChat
to join the community

Try Guance

Start online and pay only for what you use.

Get started

Choose a Guance plan

Code hosting