Start using git worktrees now

I have heard many times that after you start using git worktrees you will never go back to your previous workflow: stashing and changing branches. It took me a while to convince myself that git worktree is better. I invested very very little time but got back tons of benefits.

Start now

My folder structure is:

.
├── main # main (master) branch
└── workspaces # per topic, feature

When I’m starting something new:

# on main branch
git worktree add ../workspaces/BLOG-0000-feature -b feature/BlOG-0000-feature
cd ../workspaces/BLOG-0000-feature

I like to have descriptive names for the workspace folder. It is up to you how you name it. Interested? Keep reading.

Your usual workflow

Git branches are cheap as they say. You are in the middle of working on a feature/AWE-4321-tanstack-integration and the previous build is blocking the release pipeline. You need to switch to apply a fix. What should be a 15-minute job ends up taking longer. Usually you would stash changes or create a WIP commit.

git stash -u
git checkout main
git checkout -b fix/AWE-4323-fix-pipeline

Not very effective. In large projects you might have many long-running branches and in dynamic environments it is easy to forget what belongs to what. Enter worktrees.

Worktrees

Look at this:

.
├── main
└── workspaces
--- blog/workspaces » tree -L 1
.
├── BLOG-0000-article-from-schema-to-zod
├── BLOG-0028-improve-typography-scale
└── BLOG-0041-article-git-worktree

main is my main branch, worktrees/ (name it however you want) replace branches. Instead of branching off main branch:

# on main branch
git checkout -b feature/BLOG-0041-article-git-worktree

I do:

# on main branch
git worktree add ../workspaces/BLOG-0041-article-git-worktree -b feature/BlOG-0041-article-git-worktree
cd ../workspaces/BLOG-0041-article-git-worktree

The tree is still linked with main, but adds another level of freedom and independence.

git log

commit 59d270cc814d795357e9a2803a9f116673e3c067 (HEAD -> feature/BlOG-0041-article-git-worktree)
Author: Wojtek
Date:   Fri Aug 7 15:57:36 2026 +0200

    BLOG-0041: article draft

commit df0de4a4591560de8fe69613d2feff32ab370677
Author: Wojtek
Date:   Fri Aug 7 15:56:50 2026 +0200

    BLOG-0041: setting up plop

commit 009f68390b63f56832707d226f614af0cf4a7a70
Author: Wojtek
Date:   Fri Aug 7 15:52:42 2026 +0200

    BLOG-0041: setting up plop

commit 6bcc0a6586f72eca82385c12f6cba4f5bbf715a6
Author: Wojtek
Date:   Fri Aug 7 15:49:39 2026 +0200

    BLOG-0041: add plop for scaffolding

commit 7cb5c8a170982f606a59ead9b41d53b22bc0cb3b (origin/main, origin/HEAD, main)

You can still have as many branches as you want in a worktree, but you will not need branches that much as before. I see lots of benefits of using worktrees. Chaos mentioned in the table below may seem subjective; I agree it always depends on the scale, type, or characteristics of the project (startup, green field, small team, many teams, and so on).

WorktreesRegular workflow
Topics have representation in folders on diskOnly one tree can be open at the same time
One worktree - one branch (usually)Many branches might mean chaos
Require setting up (again)Problem doesn’t exist

Regarding the last point: Require setting up (again)

Tip

When you are switching to just created worktree, remember to copy all .env.example files and install dependencies, e.g npm install If something is ignored via .gitignore, unfortunately, it does not exist in a new worktree.

I did not like it for a long time when I started using worktrees over one year ago. Now I don’t mind and have gotten used to it.

Summary

When I turned to git worktree I started persuading my colleagues to use worktrees. Surprise, surprise, they didn’t feel as convinced as I was one year before; maybe it’s the naming, or documentation that comeacross as very robotic? I hope that my post is another one that can potentially convince you to use git worktrees. I did not describe all commands like git worktree list or git worktree remove since once you use git worktree add, the rest comes naturally.