worktree — multiple checkouts, one repo
The classic interruption story: you are mid-feature on feature/x, an urgent bug needs a fix on main, and you cannot stash because the in-progress code does not yet build. The old answer was a second clone of the repo. The modern answer is git worktree: a single .git/ shared across multiple checked-out copies of different branches. Same commits, same hooks, same config — different working trees, side by side.
git worktree add ../repo-hotfix hotfix/login creates a new worktree at ../repo-hotfix with hotfix/login checked out. The original worktree at ./repo still has feature/x. You switch projects by changing directories, not branches. The shared .git/ means commits made in either worktree are visible from the other immediately. git worktree list shows all checkouts; git worktree remove ../repo-hotfix retires one when the work is done.
Three high-leverage use cases. Hotfix during in-progress work — branch the hotfix into a worktree, fix and ship, return to the feature without ever stashing. Long-running comparison or build — run a long test against one worktree on an old commit while you keep working on the new commit in the original. Reviewing a teammate's PR — git worktree add ../repo-pr-142 pr/142 gives you their branch checked out cleanly without disturbing your main branch checkout.
Two gotchas. The same branch cannot be checked out in two worktrees at once — Git refuses. (Use git worktree add --detach if you really want a read-only view.) Worktrees consume disk: each is a full working-tree copy, just without its own .git/objects/. For huge repos, partial-clone or sparse-checkout in the secondary worktree saves significant space. The CI integration is also nice — Vercel and similar platforms can deploy each worktree independently.