`git worktree` Is the Clean Way to Check Out Two Branches at Once Without Stashing Every Five Minutes

Why this command feels like a quality-of-life upgrade: many Git frustrations come from trying to make one working directory serve too many active contexts. git worktree gives you another option: keep multiple branches checked out at once, honestly.

What git worktree does

Git can manage multiple working trees attached to the same repository. That means you can have one branch checked out in one directory and another branch checked out somewhere else, without recloning the whole repo.

A common pattern:

git worktree add ../repo-feature feature-branch

Now the same repository history supports another working directory pointed at that branch.

Why this is better than constant stash juggling

If you are bouncing between:

• a feature branch
• main
• a review branch
• a release hotfix

in one directory, you eventually spend more energy preserving local state than doing the actual work.

git worktree helps because each context gets its own working directory. That means fewer:

1. “stash this first”
2. “switch back later”
3. “what did I have modified here?”

moments.

When it is especially useful

It is a strong fit for:

• reviewing a PR while your own branch is mid-change
• keeping main available for quick reference
• testing a branch without disturbing another in-progress state

This is why developers who learn it often wonder why they spent so long overloading one checkout.

The operational habit that makes it stick

The command becomes truly useful when you give each worktree a job. For example:

• main checkout for stable commands and quick reference
• feature checkout for active development
• review checkout for PR inspection

That removes a lot of context bleed. Your feature branch stops being the place where every unrelated task briefly lands and leaves debris behind.

Cleaning up worktrees matters too

A useful lifecycle looks like this:

git worktree list
git worktree remove ../repo-feature
git worktree prune

Developers sometimes try worktrees once, never remove old ones, and conclude the feature creates clutter. The feature is not the clutter. The missing cleanup habit is.

Why this often beats recloning

Recloning is easy but wasteful when the repo is large or frequently used. Worktrees reuse the same underlying repository data, which makes them a cleaner fit for short-lived parallel contexts. You get separation without the full cost of another clone and without the fragility of repeated stash gymnastics.

The mindset shift that matters

The deeper value is not only performance. It is honesty about context. One working directory is one context. Once you accept that, the old habit of overloading one checkout starts to look obviously clumsy. Worktrees are Git acknowledging a real developer behavior: you often need more than one active branch at the same time.

That is why the feature tends to stick once somebody adopts it. It does not feel like a trick. It feels like the workflow finally matches the reality of how engineers actually work.

Final recommendation

If your current Git habit involves constant stashing just to see another branch, git worktree is probably worth adopting. Separate working directories are often a cleaner answer than more state juggling inside one folder. The command is not just convenient. It changes the workflow shape in a way that makes parallel branch work feel much less fragile.

Sources

• git-worktree documentation