You get a worktree, everyone gets a worktree - SlicerVM Blog<br>svg]:px-2.5 font-mono -ml-2" href="/blog/">Back to Blog

Prior to 2026, few people were espousing the benefits of Git Worktrees. Now the Internet cannot keep quiet, but do we need them?

If we ask why git's worktree feature got placed front of mind amongst developers, we're presented with a chicken and egg question. Did worktrees gain popularity because agents saw them as the solution to parallel work, or was it cargo culting - or a mixture of the two?

The answer is not clear. We look at how to use them, why agents may like them, and how we built support for them in Slicer's new slicer worktree command.

Oprah wants everyone to have a worktree

How to use a git worktree

Let's start with an example of when you might use one (or more).

You're building a feature for Slicer. It's a MITM proxy and you have untracked changes everywhere, you're 20 prompts deep into a really gnarly issue.

Now one of your key customers reports a typo in the "slicer up" command and you know it's trivial to fix, and you feel embarrassed. You want to get that patched and released ASAP.

Here are some options:

You run git add . followed by git stash and hope and pray that you don't forget about those changes

You run git add . then git commit even though you're not happy with the commit and the work is not complete

You run cp -r repo repo-typo and then cd repo-typo ; git checkout -b fix-typo and push up a new branch, leaving the original repo folder as it was

None of these are anti-patterns, they're all valid workflows. But another exists.

alex@:~/code/slicer$ git worktree add ../slicer-fix-typo -b fix-typo<br>alex@:~/code/slicer$ cd ../slicer-fix-typo<br>alex@:~/code/slicer-fix-typo$ # Edit file, commit, and push<br>Basic syntax:

git worktree - base command, several sub-commands are available

add - create a new worktree

../slicer-fix-typo - best to do this one level up so you don't commit a git submodule by accident

-b fix-typo - optional, checks out a new branch ready for work, you can also leave this off

Behind the scenes, a new folder is created for the worktree, which shares the base .git folder, and instead of cloning it on disk like cp -r or git clone --local, it redirects to the original path.

alex@:~/code/slicer-fix-typo$ cat .git<br>gitdir: /home/alex/code/slicer/.git/worktrees/slicer-fix-typo<br>Unlike stashed uncommitted changes, or a commit that says "WIP don't merge", or cp -r, worktrees can be listed via git worktree list

Some additional options:

usage: git worktree add [] path> [commit-ish>]<br>or: git worktree list []<br>or: git worktree lock [] path><br>or: git worktree move worktree> new-path><br>or: git worktree prune []<br>or: git worktree remove [] worktree><br>or: git worktree unlock path>

-f, --force checkout branch> even if already checked out in other worktree<br>-b branch> create a new branch<br>-B branch> create or reset a branch<br>-d, --detach detach HEAD at named commit<br>--checkout populate the new working tree<br>--lock keep the new working tree locked<br>--reason string> reason for locking<br>-q, --quiet suppress progress reporting<br>--track set up tracking mode (see git-branch(1))<br>--guess-remote try to match the new branch name with a remote-tracking branch<br>Once you've completed your work, you can push up a branch (if needed), and delete the worktree or its folder, along with the custom branch.

Why might agents like worktrees?

Caveat emptor: Remember 3 months ago when the trend was to post a selfie with a Mac Mini and the caption "Just finished onboarding my new employee"? Looking back, either people didn't need a Mac for OpenClaw, or the shine has worn off, because eBay is awash with base-model Mac Minis right now.

When I asked on X, most people answered with a variation of "it uses less disk space than copying the folder". Then I looked at my workstation with a 2TB NVMe and saw only 40% used and shrugged. Quite often folks who are following the crowd find it hard to explain exactly why they need something.

In any case, here's why agents might insist on worktrees:

They're convenient (fast via a built-in command)

They're trackable (the list command shows agents without extensive context or memories what work is in progress)

They don't use much extra disk space (think of them like a glorified symbolic link)

Personally, I tend to start an agent session for a single feature for a particular repo at a time. Maybe one for the landing page, one for the docs, one for the primary codebase. In the rare occasion I need two agents on the landing page, I'll cp -r the relatively small git repo, or start a worktree (I'm not against them!)

Put your agent into a cage with Slicer

Whilst claude code was iterating on worktrees for Slicer, he started a monologue about how he was building himself his own cage, and reassured himself not to present a dramatic manifesto about it, but to get on with the simple task. It felt almost sentient at that point. And there's something very important to...