Git worktree: The Git Command That Made Me Use stash Much Less

When I recently revisited my own Git habits, I ended up with the same conclusion again: git worktree is still an underrated command.

I used to run into the same situation all the time.

I would be halfway through work on a feature branch, with a messy working tree full of edits, when a new message arrived: there is a production issue, fix it now. The next steps were always mechanical:

git stash
git checkout main
# fix the bug
git commit
git checkout feature/xxx
git stash pop

That flow is not complicated, but it has one big problem: it breaks your momentum. If your current working tree is already messy, with new files, renames, and half-finished refactors, you instinctively do not want to touch it. Not because you cannot, but because every switch interrupts your current context.

Once I started using git worktree, that problem became much easier.

What is `git worktree`?

In one sentence:

git worktree lets a single Git repository have multiple working directories at the same time.

That means you do not need to clone the repo again, and you do not need to keep switching branches inside one directory. You can put another branch in another folder and work in both directories in parallel.

For example:

project/ keeps your current feature work
project-hotfix/ is used only for the urgent fix

The two directories do not interfere with each other, but under the hood they share the same repository data.

Git's own documentation defines it very directly: one repository can have multiple attached working trees, so you can check out multiple branches at the same time. The new directory is a linked worktree, and the original directory is the main worktree.

Why is it so practical?

The biggest value of git worktree is not that it is an "advanced Git command". It is that it matches real development better.

The most annoying thing in development is usually not typing one extra command. It is losing context.

You finally get your feature flow into your head. Your editor, terminal, logs, and runtime are all exactly where you want them. Then another task appears, and you have to pack up your current state, switch branches, do the other work, then switch back. The interruption is not just command-level. It is cognitive.

The idea behind git worktree is simple:

Do not interrupt the current workspace. Open another one.

That feels much more natural than stash + checkout.

Git's own docs even describe a very realistic case: you are in the middle of a large and messy refactor, and your boss suddenly asks for an urgent fix. The recommendation is not "stash first". It is "create a temporary worktree, fix it there, remove it, then continue where you left off."

That is exactly the kind of situation this command is built for.

How is it different from branches and clone?

My first reaction when I saw it was: so this is just another clone?

It is not.

The relationship looks more like this:

A branch is a line of development.
A worktree is one branch checked out into an independent directory.
A clone is a completely separate copy of the whole repository.

A worktree reuses the same repository data and only adds another working directory.

That gives it some clear advantages:

lighter than cloning again
much faster to create
no need to re-download history
each directory has its own HEAD, index, and uncommitted changes
ideal for parallel branch work

The Git documentation explicitly notes that linked worktrees share repository contents, but files directly tied to the workspace such as HEAD and the index remain separate. That is exactly why the feature is both lightweight and practical.

The commands you actually use

See what worktrees exist in the current repo:

git worktree list

Create a new branch from main and place it in a new directory:

git worktree add -b feature/login ../project-login main

That command does three things:

creates a new directory at ../project-login
creates feature/login from main
checks out that branch directly in the new directory

If the branch already exists:

git worktree add ../project-hotfix hotfix/payment

If you just want a temporary detached workspace:

git worktree add --detach ../project-lab

When the task is done, remove the worktree:

git worktree remove ../project-hotfix

If you manually deleted the directory, Git still keeps bookkeeping data. Clean it up with:

git worktree prune

If you manually moved the worktree directory, you can use:

git worktree repair

A workflow that feels natural in practice

Suppose I am developing a new feature in my main working directory:

~/code/project

Then an urgent hotfix arrives. I no longer stash my in-progress changes first. I open a second working directory immediately:

git worktree add -b hotfix/order-timeout ../project-hotfix main

Now I have two directories:

project/ keeps the original feature work
project-hotfix/ is used only for the hotfix

I open both in separate windows. The original feature directory stays untouched. In the new directory I fix the bug, test it, commit, and push. Once the hotfix is merged, I remove the temporary directory, and my original development context is still there exactly as I left it.

The experience feels like this:

You are not pausing one task to do another. You are opening another desk for the second task.

A few things to keep in mind

git worktree is smooth once you start using it, but a few details matter.

First, the same branch usually cannot be checked out in multiple worktrees at once. Git's documentation explicitly says that if a branch is already checked out elsewhere, Git will reject another worktree for that branch unless you force it.

Second, when removing a worktree, prefer git worktree remove. If you delete the directory directly, you can usually clean it up later with git worktree prune, but it is better to remove it properly.

Third, if a worktree lives on an external drive or a network volume that is not always mounted, consider git worktree lock. That prevents Git from cleaning up its bookkeeping automatically.

Fourth, if you often move projects between environments, look at the worktree.useRelativePaths config. Git's config documentation notes that relative paths can be useful when directories are likely to move.

If you only ever work sequentially on one branch, git worktree is not mandatory.

But if any of these sound familiar, it is worth learning:

you regularly stop feature work to fix bugs
you maintain multiple branches at the same time
you do not want to rely on stash
you want experiments in their own directory
you want to compare main and a new feature side by side

This is not a flashy command. It is a practical everyday tool.

Final thought

Most people learn Git through branch, checkout, merge, and stash. worktree tends to come much later.

But once you start using it, you realize it solves a very common problem:

How do you start a second piece of work immediately without disturbing the first one?

If I had to summarize it in one sentence:

git branch gives you multiple development lines. git worktree puts those lines on the desk at the same time.

What is git worktree?