Stop Stashing: Use git worktree for Urgent Hotfixes

6 min read · Last updated: October 25, 2026

Stop using git stash to handle interruptions. git worktree is the better tool: it checks out a second branch in a second folder, backed by the same repository, so your half-finished feature stays exactly as you left it while you ship the hotfix.

Came here from Instagram, LinkedIn, X or YouTube? Here is the full source list you came for. Everything below is built from these, nothing else.

The docs

• git-worktree manual, Git 2.56.0, September 28, 2026
• git-stash manual, Git 2.56.0, September 28, 2026

The post that prompted this

• Stop Stashing: How git worktree Lets You Work on Two Branches at Once, on Medium

Key takeaways

• git stash exists to return you to a clean working directory. That is the wrong goal when you only need a second place to work.
• git worktree add gives you one extra folder per branch, all attached to one repository.
• By default Git refuses to check out the same branch in two worktrees, which protects you from yourself.
• git worktree remove only deletes a worktree that is clean, unless you force it.
• The official manual says support for submodules is incomplete. If you rely on them, stay careful.

Why is git stash the wrong tool for a hotfix?

Because stash answers a different question. The Git manual says to use it "when you want to record the current state of the working directory and the index, but want to go back to a clean working directory." A hotfix does not need your work hidden. It needs a second place to stand.

Here is the usual dance. You are mid-feature, files modified everywhere. A hotfix lands. So you run git stash, switch branches, fix, commit, switch back, and run git stash pop.

It works. It is also fragile in four small ways:

1. Your context vanishes. Your editor tabs, running dev server and half-built state all belong to the branch you just left.
2. Untracked files are easy to forget. The manual describes -u / --include-untracked as the flag that also stashes untracked files, so without it your new files stay behind in the folder.
3. The stash is a stack, not a label. Three interruptions later you are reading stash@{2} and guessing.
4. Popping can conflict. If the hotfix touched the same files, you resolve conflicts on work you did not want to touch at all.

None of these are disasters. They are the tax you pay for using a tool built for tidying, to do the job of parallel work.

What is git worktree?

git worktree lets one repository have several working folders at once. The manual puts it plainly: "A git repository can support multiple working trees, allowing you to check out more than one branch at a time." Each extra folder is called a linked worktree. The original is the main worktree.

The key sentence is this one from the same manual: the new worktree is "sharing everything except per-worktree files such as HEAD, index, etc."

Translated: each folder has its own checked-out branch and its own staging area. Your feature folder and your hotfix folder cannot step on each other, but they are the same repository, so a commit made in one is visible to the other.

How do you ship a hotfix with git worktree?

You add a worktree for the hotfix branch, fix and push from there, then remove it. Your feature folder is never touched. Four commands cover the whole job.

# 1. From your feature folder: create a hotfix branch in a sibling folder
git worktree add -b hotfix/login-500 ../myapp-hotfix main

# 2. Work in the new folder
cd ../myapp-hotfix
# edit, test, then:
git commit -am "Fix 500 on login"
git push -u origin hotfix/login-500

# 3. Go back. Your feature work is exactly as you left it
cd ../myapp

# 4. Clean up when the hotfix is merged
git worktree remove ../myapp-hotfix

The -b flag creates the new branch, and the last argument (main) is the commit it starts from, both per the manual's add <path> [<commit-ish>] form. If you skip -b, Git creates a branch named after the last part of the path.

No stash. No switching. No pop.

Which git worktree commands do you actually need?

Five cover almost everything. All of them come from the official manual.

Command	What it does
git worktree add <path> [<commit-ish>]	Creates a linked worktree at <path>
git worktree list	Shows the main worktree first, then linked ones, with notes like locked
git worktree remove <worktree>	Deletes a linked worktree
git worktree prune	Cleans admin data for worktrees whose folders are gone
git worktree move <worktree> <new-path>	Relocates a worktree

Two more exist for edge cases. lock stops a worktree being pruned, which helps when it lives on a portable or network drive. repair reconnects worktrees you moved by hand.

What is the strongest argument for keeping git stash?

The fair objection is that stash is one command, worktree is several, and a second folder has costs. That is true for tiny interruptions. For a two-minute detour, stash is fine. Worktree wins when the interruption is real work, or when you will bounce between branches more than once.

Let me give the counter-arguments their due, one at a time.

"A new folder has no node_modules." Correct. A linked worktree is a fresh checkout, so files that are not tracked, such as installed dependencies, are not there. You run your install step once in the new folder. For a hotfix that is a one-time cost, and your feature folder keeps its own.

"It's more to learn." The core is one command, git worktree add, and one cleanup command. That is a smaller surface than a stash stack.

"I can just commit a WIP and switch." You can, and many people do. But it still swaps your working folder under your editor and running processes. A worktree does not.

"It's risky." Git builds in guardrails. By default, add refuses when the branch is already checked out in another worktree, and remove only deletes clean worktrees (no untracked files and no modifications in tracked files). You have to pass --force to override either one.

The real caveat is submodules. The manual's BUGS section says: "Multiple checkout in general is still experimental, and the support for submodules is incomplete. It is NOT recommended to make multiple checkouts of a superproject." Linked worktrees containing submodules also cannot be moved with git worktree move. If your project leans on submodules, keep using stash.

Is git worktree better than git stash?

For interruptions that become real work, yes. For a two-minute peek at another branch, stash is still quicker. The deciding question is whether you need your current state hidden, or whether you need a second place to work.

Situation	Better tool
Urgent hotfix while mid-feature	git worktree
Reviewing a teammate's branch while you keep working	git worktree
Quick look at another branch for a minute	git stash
Project built on submodules	git stash
Need to run both versions side by side	git worktree

The second row matters more every year. If you review AI-written code a lot, a throwaway worktree lets you run someone's branch without disturbing yours. I cover the review side in how to review AI-generated code like a pro.

What should you do this week?

The next time a hotfix interrupts you, do not stash. Run git worktree add, fix it in the second folder, and notice that nothing you had open moved. Do it once and the habit sticks.

1. Check your Git version with git --version.
2. Pick a sibling folder naming rule, such as ../<repo>-hotfix.
3. Use git worktree add -b <branch> <path> main for the interruption.
4. Finish with git worktree remove <path> so old folders do not pile up.
5. Run git worktree list now and then to see what is still attached.

If Git commands are still new to you, start with Git commands for beginners in 2026 first.

FAQ

What is the difference between git stash and git worktree?

git stash saves your local modifications and reverts the working directory to match HEAD, per the Git manual. git worktree leaves your changes alone and gives you another folder with another branch checked out. One hides your work. The other lets you work in two places.

Can I check out the same branch in two worktrees?

Not by default. The manual says add refuses to create a worktree when the branch is already checked out by another worktree. The --force option overrides that safeguard, but you rarely want it, because two folders editing one branch invites confusion.

How do I delete a git worktree?

Run git worktree remove <worktree>. It only removes clean worktrees, meaning no untracked files and no modifications in tracked files. If you deleted the folder by hand instead, git worktree prune clears the leftover administrative data.

Does git worktree work with submodules?

Partly. The Git manual says submodule support is incomplete and recommends against multiple checkouts of a superproject. Use it with care, or stick to stash on submodule-heavy repos.

Stashing is a fine habit for tiny detours. For real interruptions, give yourself a second folder. More developer tools are in the free tools on Art of Code, and if you are hunting for your next role, see /jobs.

Written by Adithya Guttha, Founder of Art of Code.