Lesson 28 of 30
A production bug lands while you're mid-feature with a messy working tree. You don't have to stash anything — check the hotfix branch out into a second directory instead.
12 min read
Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.
This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.
Be interviewed on this →Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.
Sign up freeWhat interviewers actually ask about this, and what a strong answer has to cover.
A strong answer covers
Likely follow-ups
A git repo has exactly one working directory... normally. git worktree breaks that assumption: it lets you check out a second branch into a second directory, both pointing at the same .git history, at the same time. Switch branches without switching directories — instead you switch directories, and each one already has its own branch checked out and ready.
This isn't a second clone. A real second clone duplicates the whole object database and needs its own fetch/push setup. A worktree shares one .git — one set of remotes, one set of objects — it just gives each branch its own checked-out files on disk.
You're three hours into a gnarly feature, half your files are mid-edit, and a production bug just paged someone. The old way: git stash, hope you remember every stash later, switch branches, fix, switch back, git stash pop, hope nothing conflicted. The worktree way: leave your feature branch exactly as it is.
$ git status
On branch feature/checkout-redesign
Changes not staged for commit:
modified: components/Checkout.tsx
modified: lib/cart/pricing.ts
$ git worktree add ../praxis-hotfix main
Preparing worktree (checking out 'main')
HEAD is now at 9f2a1c4 chore: bump deps
$ cd ../praxis-hotfix
$ git checkout -b hotfix/cart-total-rounding
$ # fix the bug, commit, push, open the PR
$ cd ../praxis
$ git status
On branch feature/checkout-redesign
Changes not staged for commit:
modified: components/Checkout.tsx # exactly as you left it
modified: lib/cart/pricing.ts
git worktree list shows every checkout sharing this repo:
$ git worktree list
/Users/adesh/praxis 9f2a1c4 [feature/checkout-redesign]
/Users/adesh/praxis-hotfix a71e0bb [hotfix/cart-total-rounding]
Two real directories, two running dev servers if you want them, one shared history. When you're done, git worktree remove ../praxis-hotfix cleans it up (or just delete the directory and run git worktree prune).
node_modules and other untracked build state don't come along for free. A new worktree is a fresh checkout of tracked files only — you'll typically need to reinstall dependencies or copy over ignored config in the new directory before it actually runs..git/worktrees/; if you rm -rf the folder instead of git worktree remove, run git worktree prune afterward or git worktree list will keep listing a directory that no longer exists.This is the same relationship a branch has to the commit graph, one level up — a branch is a movable pointer into shared history, and a worktree is a movable checkout into that same shared history. Neither duplicates the underlying data; both are cheap, disposable views onto one source of truth.