Skip to content
Tech News
← Back to articles

Working with Git Worktrees in Magit

read original get Pro Git (2nd Edition) by Scott Chacon → more articles
Why This Matters

Git worktrees are a decade-old feature that most developers never needed, but AI coding agents like Claude Code have made them newly relevant by spinning up a separate working directory per task so multiple agents can work in one repo in parallel. That shift means developers now encounter worktrees whether they sought them out or not, and tooling like Magit is where they'll manage them.

Key Takeaways
Worth a Look

Pro Git (2nd Edition) by Scott Chacon — If worktrees were a blind spot, this is the book that fills in all the others too — it covers git's plumbing, branching models, and the lesser-known commands like git worktree in depth. A solid desk reference for anyone juggling parallel branches, Magit, or AI agents spawning worktrees left and right.

See Pro Git (2nd Edition) by Scott Chacon on Amazon → Affiliate link — we may earn a commission on purchases, at no extra cost to you. Product picked by AI based on this article; it is not a tested recommendation.

I’ll admit that until fairly recently I had no idea git worktrees existed. They’ve been part of git for a decade and I never once needed them. Feature branches did the job just fine - create a branch, do the work, merge it, delete it, and start over.

What finally introduced me to worktrees was, of all things, AI coding agents. Tools like Claude Code create a worktree for each task, so several agents (or several sessions of the same agent) can work on the same repo in parallel without stepping on each other - or on you. Suddenly my projects directory was full of cider-this and cider-that siblings, and I figured I should understand what’s actually going on there.

Worktrees vs Branches

A branch is just a movable pointer to a commit, and making one is basically free. The catch is that a repository has a single working directory, so working on two branches means switching that directory back and forth. You know the routine: stash your half-done work (or commit it), check out the other branch, do the thing, check out the first branch again, unstash. It works, but it’s tedious, and it gets worse when the two branches leave your project in different build states and every switch means recompiling half the world.

A worktree gives you an additional working directory attached to the same repository:

$ git worktree add ../cider-smart-targeting -b smart-form-targeting

Now ~/projects/cider-smart-targeting is a full checkout of that branch, while your main checkout stays exactly where it was. The object database, refs, stashes and remotes are all shared - a worktree is not a clone, so fetching in one is fetching in all, and creating one is nearly instant. Each worktree gets its own HEAD and index, and git enforces one simple rule: a branch can only be checked out in one worktree at a time.

When are they worth it? Whenever two things need to happen at the same time: a long test run on one branch while you work on another, reviewing a PR without disturbing your half-done work, or - the reason everyone is talking about them these days - AI agents doing their thing in isolation. The price is pretty modest: your working files exist on disk more than once, and anything that isn’t tracked by git (dependencies, build caches, node_modules and friends) has to be set up again in each worktree.

If branches have never felt limiting to you, that’s fine - they didn’t for me either, for over a decade. Worktrees are one of those features you don’t miss until your workflow changes.

What About Jujutsu?

... continue reading