Introduction

By default, git stash saves tracked changes and ignores untracked files. If your working tree contains new files that are not yet in Git and you want to shelve them temporarily, you need to opt in explicitly. The important distinction is between stashing tracked plus untracked files and stashing absolutely everything, including ignored files.

Understand What Untracked Means

An untracked file exists in your working directory but is not part of the index and not part of the latest commit.

Check the state with:

git status --short

You might see output like:

 M src/app.js
?? notes.txt

Here, notes.txt is untracked. Plain git stash will not include it.

Use -u or --include-untracked

To stash tracked changes together with untracked files, use:

git stash push -u -m "WIP before branch switch"

The -u flag tells Git to include untracked files as part of the stash entry.

Afterward, confirm what is stored:

git stash list
git stash show -p stash@{0}

This is the standard answer when the question is specifically about new files that are not yet tracked.

Know When -a Is Different

If you also want ignored files, use -a or --all:

git stash push -a -m "Temporary stash including ignored files"

This is more aggressive than -u. It includes ignored files such as build output, cache directories, or generated artifacts.

Use it carefully. Large ignored directories can make stash operations slower and heavier than expected.

Restore the Stash Safely

There are two common ways to restore a stash:

• 'git stash apply restores the changes but keeps the stash entry'
• 'git stash pop restores the changes and removes the entry if the apply succeeds'

git stash apply stash@{0}

If you expect conflicts or want a safer first pass, apply is often better than pop because the stash entry remains available until you decide to drop it.

git stash drop stash@{0}

Stash Only Part of the Working Tree

You can also limit the stash to a path when only one part of the repository needs to be shelved.

git stash push -u -m "frontend WIP" -- web/

This is useful when you want to isolate a local experiment without disturbing unrelated work in the same repository.

You can combine that with --keep-index when you want to preserve staged changes and stash only the rest:

git stash push -u --keep-index -m "Keep staged tests, stash the rest"

That workflow is handy when you want to commit one clean part of the work while parking the unfinished files temporarily.

Use git stash branch for Older or Risky Stashes

If a stash is old or likely to conflict with the current branch state, restoring it on a fresh branch is often cleaner.

git stash branch recover-wip stash@{0}

That command creates a new branch at the stash base, applies the stash there, and drops the entry if the apply succeeds. It is often safer than applying an old stash onto a heavily changed branch tip.

Add Good Messages and Inspect Before Dropping

Stash messages are cheap and save time later. A clear message such as "WIP before hotfix" is far more useful than a pile of anonymous stash entries.

Before deleting a stash, inspect it:

git stash show -p stash@{0}

That habit reduces the chance of dropping the wrong temporary work.

Common Pitfalls

The biggest pitfall is running plain git stash and assuming untracked files were included. They were not.

Another common issue is using -a without realizing that ignored files are now part of the stash too. That can make the stash larger and messier than intended.

People also pop a stash immediately during a conflict-heavy situation and lose the easy fallback of keeping the stash entry around for another try.

Summary

• Use git stash push -u to include untracked files in a stash.
• Use -a only when ignored files also need to be shelved.
• Prefer git stash apply first when you want a safer restore path.
• Use path-limited stashes and --keep-index when only part of the work should move aside.
• Add clear stash messages so temporary work stays understandable.