Git Worktrees: A Git Feature I Wish I Had Tried Earlier

I had heard about Git worktrees before, but I didn’t really try them until recently — when a coding assistant I was using created one naturally as part of its workflow.

I was working on a feature when we realized there was a bug fix that needed to happen first because it was a prerequisite.

And that’s when worktrees clicked for me.

So… what is a Git worktree?

A Git worktree lets you have multiple working directories of the same repository on your computer, each checked out to a different branch.

Instead of constantly switching branches in one folder, you can have something like this:

/my-app-main
/my-app-feature
/my-app-bugfix

All connected to the same Git repository — but each on a different branch.

Without worktrees

Imagine you’re halfway through building a feature:

git checkout feature/new-reporting

Then you realize a bug fix must happen first because it’s blocking the feature.

Normally, the flow might look something like this:

git stash
git checkout main
git pull
git checkout -b fix/auth-token

Fix the bug, push it, merge it… then come back:

git checkout feature/new-reporting
git stash pop

Totally workable.

But there’s friction.

You interrupt your flow, mentally bookmark where you were, and juggle branch switching, stashes, and working state.

With worktrees

Instead, you can keep your feature exactly where it is and create a separate working directory for the bug fix.

From your repo:

git worktree add ../my-app-bugfix -b fix/auth-token main

Now you have:

/my-app-feature   → feature/new-reporting
/my-app-bugfix    → fix/auth-token

You can literally open both folders side by side.

Your feature stays untouched while you work on the prerequisite bug fix. When the fix is merged, you can update your feature branch and continue.

You’re still context switching.

But it feels much more graceful.

Especially with coding assistants, I’ve found this surprisingly helpful.

It makes parallel threads of work feel much more natural.

For example, I might be actively building a feature in one worktree while a separate Claude session works on a prerequisite bug fix in another — all within the same repository, but isolated from each other.

Or I might spin up a temporary worktree for an experiment without disrupting the work already in progress.

You’re still coordinating and context switching, but the friction feels much lower.

A small practice that seems helpful

It could be helfpul s keep a default worktree always synced with main, something like:

/my-app-main      → always synced with main
/my-app-feature   → current feature
/my-app-hotfix    → urgent fix

That way, creating new branches or experiments feels lightweight and you always have a clean starting point.

It’s one of those Git features I wish I had tried earlier.

Sharing in case it’s useful for someone else too.