Let’s build a rock-solid foundation before looking at any moving parts.

When you’re working in a Git repository, your edits live in your working directory — the actual files you see, open, and modify on your computer. Most of the time, you finish a piece of work and save it permanently as a commit, adding it to your project’s history. But sometimes you’re not finished. Your changes are half-done, experimental, or simply not ready to be saved as a real commit — yet you urgently need a clean working directory to do something else, like switching branches or pulling in the latest updates from teammates.

git stash solves exactly this problem. It takes your current uncommitted changes — both staged and unstaged — and saves them into a special, temporary storage area separate from your project’s regular history. Your working directory is then reset to match the last commit, giving you a clean, uncluttered starting point. Later, whenever you’re ready, you can bring those saved changes back and continue exactly where you left off.

It’s worth being precise about one thing early on: a stash is not a commit, even though it’s built using similar internal machinery. It doesn’t appear in your regular project history, it isn’t shared automatically with teammates, and it’s meant to be a short-term, personal parking spot rather than a permanent record. Keeping that distinction in mind will make everything else in this post click into place.

A handful of terms make everything about stashing far easier to reason about. Let’s define them clearly.

With this vocabulary in hand, let’s open up the hood and look at exactly what happens the moment you create a stash.

This is the heart of the whole topic — the sequence of steps hiding behind a single stashing action.

sequenceDiagram
    participant You
    participant Git as Git
    participant Stash as Stash Stack
    You->>Git: Request a stash
    Git->>Git: Capture staged and unstaged changes
    Git->>Git: Build commit-like snapshot objects
    Git->>Stash: Push new stash entry on top
    Git->>You: Reset working directory to last commit
        

Zooming out from a single stash, let’s trace the full lifecycle from the moment work begins to the moment it’s safely restored.

A typical stash’s life follows a predictable rhythm: you start editing files, something urgent interrupts you, you stash your progress, you complete the interrupting task, and then you return to restore your stashed work and continue. This cycle can repeat many times throughout a single day for a busy developer, and understanding it as a full loop — not just a single command — helps you use stashing deliberately rather than accidentally.

flowchart LR
    A[Editing files, work in progress] --> B[Urgent interruption arrives]
    B --> C[git stash: capture and clear]
    C --> D[Working directory now clean]
    D --> E[Handle the urgent task]
    E --> F[Return to original work]
    F --> G[Restore stash: apply or pop]
    G --> H[Continue exactly where you left off]
        

Notice that the stash itself doesn’t disappear the moment you create it — it patiently waits on the stash stack for as long as you need, whether that’s a few minutes or, less ideally, several days. The longer it waits, the more the rest of your project may have moved on around it, which is why timely restoration matters, a point we’ll return to in the best practices chapter.

Both actions “save” your changes in some sense, so it’s worth being precise about how they genuinely differ.

This distinction explains why developers reach for a stash instead of a commit when they’re interrupted mid-thought: committing implies “this is a finished, meaningful checkpoint,” while stashing openly acknowledges “this isn’t ready yet, but I don’t want to lose it either.”

Restoring a stash isn’t a single action — there are two closely related approaches with one important difference.

Stashing isn’t limited to one saved state at a time — understanding the stack structure unlocks a lot of flexibility.

Every time you create a new stash, it’s added to the top of your personal stash stack, while any earlier stashes remain safely underneath, unaffected. This means you can stash multiple, entirely unrelated pieces of unfinished work over the course of a busy day, each waiting patiently in its own slot until you’re ready to deal with it.

flowchart TD
    A[Stash Stack] --> B["stash@{0} — most recent"]
    A --> C["stash@{1} — created earlier"]
    A --> D["stash@{2} — created even earlier"]
        

Each entry in the stack can be referenced individually, inspected on its own, applied independently, or dropped without touching the others. This is especially useful when several genuinely separate interruptions happen back to back — you don’t need to resolve the first one before stashing again for the second.

Stashing doesn’t have to be all-or-nothing — you can be selective about exactly which changes get tucked away.

By default, a stash captures every uncommitted change across your entire working directory. But sometimes only some of your changes are actually ready to be set aside, while others need to stay visible so you can keep working on them. Interactive and selective stashing modes let you choose specific files, or even specific portions within a single file, to include in the stash — leaving everything else exactly as it was.

Not every file in your working directory is treated equally by default, and this trips up plenty of developers the first time they hit it.

By default, a standard stash only captures changes to files Git is already tracking — meaning brand-new files you’ve created but haven’t yet introduced to Git go completely untouched, remaining visible in your working directory even after stashing. This can be surprising if you expected a fully clean slate. Special options exist specifically to also sweep untracked files into the stash, and separately, to include files that are deliberately ignored by the project altogether.

A stash you can’t identify later is far less useful than one you can. Here’s how to keep track of what’s actually stored.

Like any convenience tool, stashing brings genuine benefits alongside a few things worth watching carefully.

Stashing is generally safe, but a handful of real risks deserve careful attention.

Beyond the mechanics, a few recurring usage patterns are worth recognizing — both the healthy ones and the ones to avoid.

A short list of habits turns stashing from an occasional emergency tool into a smooth, reliable part of your daily workflow.

This isn’t a niche, rarely-used feature — it’s woven into the daily rhythm of professional software development.

No. A stash lives entirely outside your branch’s regular commit history and stays local to your own machine unless you take deliberate additional steps to share it.

Stashed work is reasonably safe while it sits on the stack, but it can be lost if you deliberately drop it, or in rare cases through aggressive repository housekeeping if it’s left unreferenced for an extremely long time. Restoring promptly avoids this entirely.

Git will pause and mark the conflicting sections directly in your files, just as it does during a regular merge conflict, giving you the chance to resolve them carefully before continuing.

Yes. A stash isn’t permanently tied to the branch it was created on, and restoring it elsewhere is a common, valid workflow, though it increases the chance of conflicts if the branches have diverged significantly.

There’s no meaningful practical limit, but accumulating too many unnamed, forgotten stashes quickly becomes unmanageable, which is exactly why the best practices in this post emphasize restoring them promptly.

git stash gives developers a safe, temporary parking spot for unfinished work, letting them clear a messy working directory instantly without the commitment of a real commit. Behind the scenes, it captures your current changes into a commit-like snapshot, pushes it onto a personal stash stack, and resets your working directory to a clean state — all reversible at any time through applying or popping. Understanding the distinction between stashing and committing, the difference between applying and popping, how the stash stack handles multiple entries, and the quirks around untracked files transforms this feature from a vaguely understood emergency button into a precise, everyday tool for managing interruptions gracefully.