Git Stash: Save Uncommitted Changes and Get Them Back

Your working directory is full of half-finished changes, and suddenly you need to switch to something else right now. You're not ready to commit (the code doesn't even work yet) but you can't afford to lose it either. That's exactly what git stash is for: it tucks your uncommitted changes into a safe place, gives you a clean working directory, and lets you pull everything back out when you're ready.

All the content from our Boot.dev courses are available for free here on the blog. This one is the "Stash" chapter of Learn Git 2. If you want to try the far more immersive version of the course, do check it out!

What Does Git Stash Do?

Picture this: you're a junior developer, three whole days into the job, and to your mother's surprise, you're still employed. Here's the workflow you've been using:

1. Commit some changes on your feature branch
2. Open a pull request from your feature branch to main
3. Checkout a new feature branch and start on the next task

Today however is a big day. The customers are complaining about a critical bug and the CEO saw you first. She's asked you to drop everything and fix it immediately... but you've got a bunch of unstaged changes that you're not ready to commit yet, and that you don't want to lose.

What do?

Many Git n00bs would create a second clone of the repo at this point (a huge mistake... if you genuinely need multiple checkouts of the same repo, that's what git worktree is for). You're better than that.

The git stash command records the current state of your working directory and the index (staging area). It's kinda like your computer's copy/paste clipboard. It records those changes in a safe place and reverts the working directory to match the HEAD commit (the last commit on your current branch).

To stash your current changes and revert the working directory to match HEAD:

git stash

To list your stashes:

git stash list
# stash@{0}: WIP on main: 78e5c03 add login page

How Do You Get Stashed Changes Back?

Stash has a few options, but the ones that you'll use most are:

git stash
git stash pop
git stash list

The pop command will (by default) apply your most recent stash entry to your working directory and remove it from the stash list. It effectively undoes the git stash command. It gets you back to where you were.

So the emergency workflow looks like this: stash your half-finished work, fix the critical bug on a clean working directory, commit the fix, then pop your stash and pick up right where you left off. No junk commits, no lost work, no second clone of the repo.

What Is the Stash, Exactly?

The git stash command stores your changes in a stack (LIFO) data structure. That means that when you retrieve your changes from the stash, you'll always get the most recent changes first: git stash pushes a change onto the stash, and git stash pop pops it back off.

A "stash" is a collection of changes that you've not yet committed. They might just be "raw" working directory changes, or they might be staged changes. Both can be stashed. So, for example, you can:

1. Make some changes to your working directory
2. Stage those changes
3. Make some more changes without staging them
4. Stash all of that

When you do, the stash entry will contain both the staged and unstaged changes, and both your working directory and index will be reverted to the state of the last commit. It's a very convenient way to "pause" your work and come back to it later.

Under the hood, a stash entry is stored as a couple of commit objects. If you're curious how Git actually stores all this stuff, read Git Internals.

Can You Have More Than One Stash?

Yep. The stash is a stack, so you can push as many entries onto it as you want. You can also stash changes with a message. I rarely use a stash message personally because I rarely have more than one stash entry. I imagine if you keep a crazy deep stash then messages are useful, but I find that I usually stash, and then just a few minutes or hours later, I pop it back out. That said, here's the syntax to provide a message:

git stash -m "jdsl v0 almost working"

If you stash twice (say, that first attempt and then a second one a few minutes later), git stash list shows both entries, newest first, with their messages:

git stash list
# stash@{0}: On main: jdsl v1 still almost working
# stash@{1}: On main: jdsl v0 almost working

Because it's a stack, stash@{0} is always the most recent entry, and it's the one git stash pop grabs by default.

Git Stash Pop vs Apply (and Drop)

pop isn't the only way to get changes out of the stash. git stash apply will apply the most recent stash changes, just like pop, but it will keep the stash in the stash list:

git stash apply

git stash drop does the opposite: it removes the most recent stash from the stash list without applying it to your working directory:

git stash drop

Most stash commands also allow you to reference a specific stash by its index (indexes count from zero, so stash@{2} is the third most recent entry):

git stash apply stash@{2}
git stash drop stash@{2}

One thing to watch out for: popping or applying a stash onto files you've since changed can cause conflicts, and you resolve them the same way you'd resolve merge conflicts. If a pop hits a conflict, Git keeps the entry in the stash list just in case, so you'll need to git stash drop it manually once you've sorted things out.

The stash is best for quick "pause and resume" moments. If you're going to be juggling two pieces of work for more than a few hours, you're usually better off with proper branches. And if you want hands-on practice with stashing, conflicts, rebasing, and the rest of the advanced workflows, that's exactly what Learn Git 2 is for — or start with Learn Git if you're still new to version control.