Git stash temporarily records selected local work so the working tree can be changed or cleared for another task. It is convenient for an interruption, but it is not a complete backup of every file, and applying a stash later can conflict with the new state of the branch.
A safe workflow knows what was saved, what remained outside the stash, and how restoration will be verified. This guide explains scope, inspection, apply versus pop, and cleanup without treating a stash entry as a guarantee that no local work can be lost.
Inspect the current work before saving it
Read status and the relevant diff. Distinguish tracked modifications, staged changes, untracked files, and ignored files. A stash command’s options determine which categories are included, so the directory’s visible contents alone do not establish coverage.
Identify important local files that need a separate backup or another supported preservation method. Credentials and machine-specific configuration deserve deliberate handling. Recording them in Git objects can create sensitive local state even if they never reach the remote.
Decide whether a temporary branch and commit would be clearer for substantial work. A stash is useful for a short interruption, while a named branch can provide a more visible history and collaboration path for a longer-lived change.
Choose scope deliberately
Git’s normal stash behavior focuses on tracked work according to the documented command. Supported options can include untracked or ignored files, but these broaden what is recorded and removed from the working tree. Do not add them casually to a habitual alias.
Use path selection when the interruption concerns only a reviewed subset, and verify the result. Leaving other modifications in place can be appropriate, but it should be intentional. A supposedly clean checkout may still contain excluded work.
Keep staged-state expectations explicit. Restoring content and restoring index state are related but distinct behaviors. Read the relevant options and test the workflow when staging matters to the next commit.
Give the entry useful context
A descriptive message can identify the task and intended branch. The basic pattern for reviewed tracked work is:
git stash push -m "interrupted report refactor"
git stash listThese commands modify and inspect local repository state; they are not a universal preservation plan. Confirm status afterward and inspect the saved entry before assuming it contains everything important.
Stash references can shift as entries are added or removed. Record enough context to identify the intended entry later rather than assuming the latest one is always yours. In a repository used by several local workflows, ambiguous numbering creates avoidable mistakes.
Inspect before restoration
Review the entry’s diff and the target branch’s current state. Applying old work onto a changed branch can produce conflicts or a patch that is textually clean but semantically wrong. Compare the intended task and surrounding code.
Use a controlled branch or worktree if the restoration needs investigation. Avoid applying an uncertain stash on top of unrelated uncommitted changes. Separating the recovery experiment makes it easier to explain which changes belong together.
Git provides supported ways to inspect stash content, including options for relevant saved categories. Do not assume one default diff view displays every untracked file or index detail that your earlier command recorded.
Distinguish apply from pop
Apply restores a selected stash’s changes while retaining the entry. Pop attempts restoration and removes the entry when the operation succeeds according to Git’s behavior. Retaining the entry until verification can provide a useful recovery margin.
If pop encounters conflicts, Git documents that the stash is not removed automatically. Resolve the conflicts and verify the result before deciding whether to drop the entry. Do not remove it merely because conflict markers disappeared.
A retained entry can also be applied more than once accidentally. Keep the workflow explicit and inspect current changes before repeating an operation. Presence in the list does not mean the work is absent from the working tree.
Resolve conflicts using intent
Read both the saved change and the current branch behavior. A conflict resolution should implement the intended work in the new context, not blindly select one side. Review unchanged-looking areas that depended on the old code.
Run the relevant tests and inspect the staged diff before creating a commit. A stash restoration is an input to development, not proof that the change is complete or compatible. Keep unrelated files out of the final commit.
If restoration becomes difficult, use Git’s documented branch-from-stash workflow where appropriate. Understand how it affects the stash entry and branch creation, and protect other local work before trying a recovery path.
Verify preservation and cleanup
Confirm the restored files, intended index state, and any required untracked material. Compare against the saved entry or another known reference. Do not rely solely on a successful command exit status as proof that the business change was preserved.
Drop entries only after the work has been safely recorded or is no longer needed. Clearing the entire stash list is broader than removing one reviewed entry. Make destructive cleanup a separate deliberate action.
Do not promise indefinite recovery after a stash is dropped. Repository maintenance and object reachability affect what remains available. Important work should have an appropriate durable preservation method rather than depending on an accidental recovery opportunity.
Consider secrets and machine-local state
A stash is normally local, but its contents still reside in repository data and can enter backups or be shared through unusual workflows. Treat a stashed credential as sensitive. Ignore patterns do not automatically protect it if you deliberately include ignored files.
If a real secret is exposed through a shared repository or artifact, rotate it through the provider’s supported process. Removing a stash entry or changing an ignore rule is not credential revocation.
A practical interruption scenario saves a small tracked refactor, verifies the entry, switches to a clean maintenance branch, and later applies it on a dedicated development branch. The developer reviews conflicts, runs tests, commits the intended work, and only then drops the temporary entry.
Frequently asked questions
Does the default stash save every file?
No. Tracked, untracked, and ignored categories have distinct supported behavior. Choose and verify the intended scope.
Is pop always safer than apply?
No. They differ in entry retention. Choose a workflow that preserves a useful recovery path until the result is verified.
Where should I check the exact options?
Read the Git stash documentation. For preserving and inspecting local reference history separately, see our Git reflog recovery guide.
