It is a familiar Monday-morning script: you are three commits into a feature, the working tree is a mess, and someone says production is broken. So you stash, fix the thing, commit, and unstash — then spend ten minutes untangling the merge. The odd part is that Git has had a proper answer since July 2015, when Git 2.5 shipped with a subcommand most of us still never touch: git worktree.
A worktree is a second checkout of the same repository, living in its own folder. Where a clone duplicates everything and then drifts out of sync, a linked worktree shares the main repository's object database and branches while keeping its own working files, index, and HEAD. In a linked worktree, .git is not a directory at all: it is a small file containing a single line like gitdir: /path/to/repo/.git/worktrees/hotfix that points back at the repository you came from. One repository, as many checkouts as you want. The idea shipped as experimental in Git 2.5; a decade of releases later it is a stable, fully documented part of the tool.
The core command is one line:
git worktree add -b hotfix ../hotfix
Git creates ../hotfix, makes a new hotfix branch from your current HEAD, and checks it out there. Your feature branch and its dirty files stay exactly where they are. Want to branch off something other than HEAD? Pass a starting point:
git worktree add -b fix/api ../fix origin/main
If you leave off -b, Git names the branch after the directory: git worktree add ../docs hands you a docs branch. I ran all of these while the current branch had uncommitted changes — nothing needed to be stashed, committed, or restored.
The workflow is boring in the best way. Fix the bug in ../hotfix, commit, push, and when you are done, git worktree remove ../hotfix. The remove subcommand arrived in Git 2.17 (Q2 2018); before that you deleted the folder yourself and ran git worktree prune to clean up the administrative files. Remove is polite: it refuses to delete a worktree with modified or untracked files (fatal: '../hotfix' contains modified or untracked files, use --force to delete it), and the main worktree can never be removed at all. Delete a worktree folder by hand instead, and git worktree list marks it prunable until prune sweeps it away.
Two facts worth remembering. First, the same branch can only be checked out in one worktree at a time; Git refuses the second checkout with a fatal error naming the other location. It reads as an annoyance until you realize it is the guardrail that keeps the two checkouts from fighting over the same refs — the worktrees know about each other. Second, for long-running tests or a clean look at an old tag without touching any branch, git worktree add --detach ../tester main gives you a detached HEAD in its own directory. And when you want to script against all of this, git worktree list --porcelain prints a format that Git promises to keep stable across versions and configuration.
That is the pitch: no stash, no WIP commits, no second clone to keep in sync, no plugin to install. Just a command that has been quietly living inside Git for over a decade. Next time production catches fire, give the fire its own directory.