How to git stash specific files only
Sometimes you only want to set aside one file, or one change inside a file, and keep working on the rest. Plain git stash sweeps up everything. Here is how to be surgical about it from the command line.
New to cloud? CAMPUX is a free, build-first course. Start here →
To stash only specific files, use git stash push path/to/file1 path/to/file2 (older Git: git stash push -- <paths>). To stash only selected changes within files interactively, use git stash push -p and answer y/n per hunk. Restore with git stash pop or git stash apply. The rest of this note walks each of those commands and the traps around them.
The short answer
A plain git stash takes every tracked change in your working tree, tucks it away, and hands you a clean slate. That is fine when you want to drop everything, but it is the wrong tool when you have three files open and only want to shelve one of them. Modern Git solves this with git stash push, which accepts file paths:
git stash push src/config.js
Only src/config.js gets stashed. Your other edits stay right where they are, still in the working tree, still ready to commit. That single behaviour is what most people are actually looking for when they search for this.
Stash specific files by path
The general form is git stash push followed by one or more paths. List as many as you like, separated by spaces:
git stash push src/config.js src/routes/auth.js
Both files are set aside together as a single stash entry; everything else is untouched. If a path could be mistaken for a branch name or an option, put a -- before it so Git knows the rest of the line is file paths:
git stash push -- src/config.js
You will also see the older, shorter spelling git stash -- <path> in blog posts and answers online. It works, but the push subcommand is the one Git documents now, and it is the only form that takes paths cleanly, so reach for git stash push and treat the bare git stash as the "everything" version. One caveat worth saying early: naming a path does not override the untracked-files rule. If the file you name is brand new and Git has never tracked it, you still need the -u flag for it to go anywhere — more on that at the end.
Stash only some changes with -p (interactive)
Paths get you file-level control. Sometimes even that is too coarse: you have edited one file in two places, and you only want to shelve one of those edits. That is what the patch flag is for:
git stash push -p
Git walks you through your changes one hunk at a time — a hunk being a contiguous block of changed lines — and asks what to do with each. The prompt looks like Stash this hunk [y,n,q,a,d,s,e,?]? and the answers you will actually use are:
y— yes, stash this hunk (set it aside).n— no, leave this hunk in the working tree.s— split this hunk into smaller ones, so you can pick a subset of the lines instead of the whole block.q— quit; stop here and stash whatever you have already said yes to.
So if you want to shelve half the edits in a file and keep the other half, run git stash push -p, press y on the hunks you want gone, n on the ones you want to keep, and Git stashes only the yes hunks. The s answer is the quiet hero here: when a hunk lumps together a change you want and one you do not, splitting it lets you answer y/n at a finer grain. You can point the patch flag at a specific file too — git stash push -p src/config.js — to walk the hunks in just that one file.
There are ways to fake this with git add and a temporary commit, but git stash push -p does it in one step and never touches your commit history. If you have ever staged part of a file with git add -p, this is the same interactive engine — same hunk prompts, same s to split — pointed at the stash instead of the index.
Naming and inspecting your stash
Stashes are easy to forget. By default they get a terse auto-message like WIP on main: 3f2a1c9 Fix login, which tells you almost nothing three days later. Give the stash a real label with -m, and it goes right before the paths:
git stash push -m "half-done auth refactor" src/routes/auth.js
Now list what you have shelved:
git stash list
You get one line per entry, each with a reference like stash@{0} for the newest, stash@{1} for the one before it, and your message alongside. To see what is actually inside an entry before you restore it, ask for the patch:
git stash show -p stash@{0}
That prints the full diff the stash holds, so you can confirm it is the change you think it is. Skip the -p and you get a short summary of files changed instead of the line-by-line diff — handy when you just want to remember which files an entry covers.
Restoring: pop vs apply
When you are ready to bring the changes back, you have two verbs, and the difference between them catches people out. Both reapply the stashed changes onto your current working tree. What they do to the stash afterwards is where they part ways:
git stash pop
pop reapplies the newest stash and then deletes that entry from the list. It is the "I'm done, put it back" command, and it is what you want most of the time.
git stash apply stash@{0}
apply reapplies the entry but leaves it in the stash list. Use it when you want the same shelved change on more than one branch: apply it on the first branch, switch, apply it again on the second, and only then throw it away. You throw it away by hand with:
git stash drop stash@{0}
Both pop and apply take an explicit stash@{n} if you do not want the most recent one; with no argument they act on stash@{0}. One honest warning: if you have edited the same lines since stashing, reapplying can hit a merge conflict. pop in particular will report the conflict and, importantly, keep the stash entry around instead of dropping it, so you do not lose your work while you sort the conflict out.
Name the files you mean, or pick the hunks you mean. Then restore with pop when you are done, apply when you are not.
Common mistakes (untracked files need -u)
The single most common surprise: a new file you have never committed does not get stashed. Plain git stash — and git stash push with paths — only handles files Git already tracks. A brand-new file sits there in the working tree, ignored by the stash, and people assume the stash "lost" it. It did not; it never took it. The fix is the untracked flag:
git stash push -u src/new-feature.js
The -u (or --include-untracked) tells Git to sweep up untracked files too. If you also want files that match your .gitignore, the bigger hammer is -a (--all), though that one is worth a second thought — it will happily stash build output and local config you probably meant to ignore for a reason.
A couple of smaller traps while they are fresh. When you use -p, the paths still matter: git stash push -p with no path walks every changed tracked file, which can be a long march in a big diff, so add a path to keep it focused. And after a pop, always glance at git status — if a conflict came up, the entry is still in git stash list and you resolve the conflict before dropping it yourself. Get those three habits down — name paths, remember -u, check status after pop — and partial stashing stops being fiddly.
Questions people also ask
Can you stash a single file in Git?
Yes. Pass the path to git stash push, for example git stash push path/to/file. Only the changes in that file are stashed; everything else in your working tree stays exactly as it was. You can name several files in the same command, and on older versions of Git you write git stash push -- path/to/file to be safe about the path.
What is the difference between git stash pop and apply?
Both reapply the stashed changes to your working tree. The difference is what happens to the stash entry afterwards: git stash pop reapplies the changes and then deletes the entry from the stash list, while git stash apply reapplies them and leaves the entry in place. Use apply when you want to restore the same changes onto more than one branch, then remove it later with git stash drop.
Does git stash include untracked files?
Not by default. A plain git stash only sets aside tracked files that have changes, so brand-new files Git has never seen are left behind. Add the -u flag (git stash push -u) to include untracked files, or -a to include ignored files as well. If you name paths and one of them is untracked, you still need -u for it to be stashed.
How do I stash only part of a file?
Use git stash push -p, which walks you through each change hunk and asks y or n to stash it. Answer y for the hunks you want to set aside and n for the ones you want to keep in your working tree. If a hunk is too large, press s to split it into smaller pieces so you can choose more precisely.