We’ve all been there: you’re deep in the flow of implementing a complex new feature, and suddenly, a critical production bug is reported. You need to switch branches immediately, but your current working directory is a mess of half-finished logic and experimental code. You can’t commit because the code doesn’t even compile, and you don’t want to lose your progress. This is exactly why you need a reliable git stash multiple changes guide in your toolkit.

In my experience, the basic git stash command is often too blunt. It takes everything and hides it away. But as projects grow, you often need more granularity—stashing only specific files or even specific lines of code. In this tutorial, I’ll show you how to move beyond the basics and manage your workspace with surgical precision.

Prerequisites

Step 1: Stashing Specific Files

Sometimes you’re working on two different things at once—perhaps a UI tweak and a backend API change. You only want to stash the UI work to clear the way for a backend hotfix. Instead of a blanket stash, use the push command with a path.

# Stash only a specific file
git stash push -m "UI tweaks for landing page" path/to/ui-component.jsx

# Stash multiple specific files
git stash push -m "Frontend updates" src/components/Header.jsx src/styles/main.css

By using -m, I always give my stashes a descriptive name. If you don’t, you’ll end up with a list of “WIP on main” entries that are impossible to distinguish a week later.

Step 2: Interactive Stashing (The Surgical Approach)

What if you have a file with 50 lines of changes, but only 10 of them are ready to be set aside? This is where the interactive patch mode comes in. This is the most powerful part of any git stash multiple changes guide.

git stash push -p -m "Partial feature implementation"

When you run this, Git will break your changes into “hunks.” For each hunk, it will ask you Stash this hunk [y,n,q,a,d,j,J,g,/,e,?]?. I typically use y to stash it or n to keep it in my working directory. This allows you to keep the critical parts of your experiment visible while clearing out the noise.

Step 3: Managing and Recovering Multiple Stashes

Once you’ve stashed several different sets of changes, you need to know how to find and apply them without creating a merge conflict nightmare. As shown in the terminal output below, your stash is actually a stack.

# List all stashes
git stash list

You’ll see something like stash@{0}: On main: UI tweaks for landing page. To bring those changes back, you have two main options:

If you find yourself frequently dealing with complex branch movements, you might also find it useful to learn how to rename git branches locally and remotely to keep your organization tight.

Terminal output showing the result of git stash list with multiple named stashes
Terminal output showing the result of git stash list with multiple named stashes

Pro Tips for Stash Power Users

After using Git for years, here are a few workflows that saved my skin:

Troubleshooting Common Stash Issues

“Conflict while popping stash”
This happens when the code you changed in the stash overlaps with changes made to the branch in the meantime. Don’t panic. Git will mark the conflicts just like a merge. If you’re using VS Code, you can follow my guide on how to fix git merge conflicts in VS Code to resolve these visually.

“I forgot to name my stash and now I have 10 of them”
Use git stash show -p stash@{n} to see the actual diff of a specific stash before you pop it. This prevents you from applying the wrong set of changes to your current branch.

What’s Next?

Now that you’ve mastered stashing multiple changes, you can handle any context-switch with confidence. To further refine your version control workflow, I recommend exploring advanced rebasing techniques or automating your commit messages with pre-commit hooks.