Should I apply or pop a Git stash when bringing saved work back?

The choice is whether you want to retain the saved stash entry as a fallback. git stash apply reapplies the saved state and leaves the entry in the stash list. git stash pop applies it and removes the entry if applying succeeds. [S1]

If you are uncertain, or want to check the returned work before removing the saved copy, start with apply. If you deliberately want a one-step restore-and-remove operation, pop is appropriate—but still inspect the result. Both commands apply changes on top of your current working-tree state, which may differ from the state in which you made the stash. [S1]

After either command, run git status. It reports changes between the index and HEAD, changes between the working tree and the index, untracked paths, and unmerged paths. [S2] Look for the files you expected to return and for any paths marked as unmerged; status is an inspection tool, not a backup. [S2]

Then inspect the relevant diffs rather than relying on a clean-looking summary alone. For example, if you expected edits in src/example.js, inspect that file’s diff and confirm the intended edits are present. If your work involved staged changes, check the index as well as the working tree: the two are reported separately by status. [S2]

According to the Git stash documentation, when applying a stash conflicts, pop does not remove that stash entry. Resolve the conflicts manually, inspect the resulting working tree and index, and drop the retained stash only after you have checked that the changes are safely back. [S1]

For example, assuming the entry you used is still identified as stash@{0}, you can inspect the current state with git status and examine the affected file diffs. Don’t assume the stash is gone just because you used pop, and don’t drop it merely because conflict markers have been addressed: first verify the result you intend to keep. The documentation explains the retention behavior, but it does not establish that any particular conflict resolution is correct for your project. [S1] [S2]

Use apply when keeping the stash entry while you inspect or continue working is useful. Use pop when you want Git to remove the entry after a successful application. In either case, judge success by the files and changes you expected—not just by the command finishing. Git notes that the current working-tree state can differ from the stash’s original context, so review carefully. [S1]

A reusable sequence, assuming you intend to restore the most recent stash, is:

1. Run git stash apply if you want to keep the entry, or git stash pop if you want it removed after successful application.
2. Run git status and check for expected changed or untracked paths and any unmerged paths. [S2]
3. Inspect diffs for the relevant files and check both staged and unstaged changes as needed. [S2]
4. If conflicts occurred, resolve and review them. If the stash entry remains, drop it only after verifying that the work you need is safely present. [S1]

This is a check-and-choice guide, not a guarantee that applying will be conflict-free or that a reviewed diff is correct for your project.