Should I use git stash apply or pop during risky recovery?

Use git stash apply during risky recovery because it keeps the stash entry available for retries.

What if I resolved conflicts but the stash entry still exists?

Verify the resolved commit first, then drop the stash entry explicitly only after confirming no recovery rollback is needed.

Can I recover dropped stash content?

Yes. Use git reflog to locate the stash-related commit, create a rescue branch, and reapply only the required changes.

Git Stash Conflict Recovery Decision Tree: Resolve, Abort, or Reapply Safely (2026)

Published February 28, 2026 · 8 min read

Start here: run Git Diff Viewer before staging conflict resolutions so you can verify exactly what changed after stash apply/pop.

Related high-intent fixes: if branch ownership fails after recovery, use Git Worktree Already Checked Out Fix. If push is still rejected after conflict resolution, follow Git Push Rejected (Non-Fast-Forward) Guide.

Stash conflicts are recoverable when you make the next move based on current state instead of habit. This decision tree gives a deterministic path for each failure mode.

Decision tree: resolve vs abort vs reapply
Copy-paste command blocks
Prevention checklist
FAQ

1. Decision tree: resolve vs abort vs reapply

Node A: Conflicts are small and branch is correct

Check: git status shows expected branch and limited conflicted files.

Action: Resolve markers, stage files, commit once, then verify stash state with git stash list.

Node B: You applied stash on the wrong branch

Check: branch name does not match intended target, or resulting diff looks unrelated.

Action: Create a rescue branch, save patch, switch to correct branch, reapply via git stash apply.

Node C: Stash entry seems dropped or missing

Check: git stash list does not contain expected entry.

Action: Run git reflog --date=iso, branch from candidate hash, extract needed changes.

Node D: Recovery collides with worktree ownership error

Check: Git reports branch already checked out in another worktree.

Action: follow Git Worktree Already Checked Out Fix, then resume stash recovery.

Warning: Avoid immediate git reset --hard while conflicts are unresolved. Create a rescue branch first so rollback remains possible.

2. Copy-paste command blocks

# baseline snapshot
git status
git stash list
git diff --name-only --diff-filter=U

# safe checkpoint branch
git switch -c rescue/stash-conflict-$(date +%Y%m%d-%H%M)

# optional patch snapshot
git diff > /tmp/stash-conflict.patch

# resolve-in-place path
git add path/to/conflicted-file
git diff --name-only --diff-filter=U
git commit -m "resolve stash conflict"

# wrong-branch reapply path
git switch your-target-branch
git stash apply stash@{0}

# dropped-stash recovery path
git reflog --date=iso
git switch -c rescue/stash-recovery <reflog-hash>

For broader stash mechanics and edge cases, see Git Stash Pop Conflict Recovery Guide.

3. Prevention checklist

Prefer git stash apply over pop when branch context is uncertain.
Confirm branch with git branch --show-current before applying stash.
Use a rescue branch before high-risk conflict resolution.
Drop stash entries only after successful verification.
Run one final diff review before push.

FAQ

Should I always resolve conflicts immediately after stash pop?

Only if branch and file set are correct. If context is wrong, checkpoint and reapply on the intended branch.

Is stash apply safer than stash pop?

Yes in recovery scenarios, because apply keeps the stash entry available for retries.

How do I proceed after conflict resolution if push is rejected?

Use Git Push Rejected (Non-Fast-Forward) Guide to sync and push safely.