Git Worktrees Are Having a Moment Because of AI Agents
Worktrees have existed since 2015. They got popular in 2026 because we stopped working one branch at a time.
Git worktrees have been in Git since 2015. Almost nobody used them. Then 2026 happened, everyone started running coding agents in parallel, and suddenly worktrees are the default mode in half the new AI dev tools. The feature did not change. The way we work did.
If you have not touched them, a worktree lets you check out more than one branch of the same repo into separate folders at the same time, all backed by one .git. That is the whole idea. The reason it matters now is that "one developer, one branch, one folder" stopped being how a lot of us work the moment we started kicking off three agent sessions before lunch.
The pain worktrees remove#
Picture the old way. You are deep in a feature branch and an urgent bug lands. To switch, you do something like this:
git stash push -m "wip feature login"
git checkout main
git pull origin main
git checkout -b hotfix-bug
# ...fix, commit, push, open PR, merge...
git checkout main
git pull origin main
git branch -d hotfix-bug
git checkout feature-login
git stash popEvery one of those checkout lines rewrites your working directory. Your editor reloads. If the two branches have different dependencies, you are reinstalling node_modules or rebuilding a virtualenv. Then you stash pop and try to remember where you were. The commands are cheap. The context switch in your head is not.
I have done the dumb workaround too: cloning the same repo two or three times into different folders so I could keep both states open. It works, but now each clone has its own .git, its own remotes, and they drift. Worktrees are the clean version of that hack.
The same switch, with worktrees#
You never leave your branch, you never stash, and your editor for the original feature stays exactly as it was:
git worktree add ../hotfix-workspace -b hotfix-bug mainThat one command creates a sibling folder hotfix-workspace, based on main, with a new branch hotfix-bug checked out. Open it in a second editor window or cd into it:
cd ../hotfix-workspace
# ...fix the bug...
git add .
git commit -m "fix broken submit button"
git push origin hotfix-bugMerge the PR online like normal. When it is done, delete the folder:
cd ../main-project
git worktree remove ../hotfix-workspaceNo stash conflicts, no editor disruption, no rebuilding the feature branch's state. Your feature window never moved. That is the appeal in one sentence: parallel branches without parallel clones.
A few commands worth knowing beyond add and remove:
git worktree list # show every worktree and its branch
git worktree add ../review origin/some-pr-branch # check out an existing branch
git worktree prune # clean up metadata for folders you deleted by handWhy now, and not in 2015#
For years worktrees were invisible. Most Git GUIs ignored them or treated them as second-class, and the feature-branch-then-PR loop worked fine when you did one thing at a time.
What changed is parallelism. AI made it normal to run several coding sessions at once: one agent refactoring a module, another writing tests, you reviewing a third. You cannot point three agents at one working directory. They will trip over each other's uncommitted changes instantly. Each agent needs its own isolated checkout, and worktrees are the cheapest way to give it one without cloning the repo three times.
This is why worktrees are the default in the GitHub Copilot app and in tools like Claude Code: when you start a session, it spins up a fresh worktree so that session has a clean, isolated place to work. Code review culture is growing faster than code writing culture, and reviewing several parallel branches at once is exactly what worktrees are good at. If you are thinking about how to structure agents that run side by side, this pairs well with my notes on the supervisor pattern.
The catch (there is always a catch)#
Worktrees are not free. The things to watch:
- Dependency bloat. Each worktree is its own folder, so each needs its own
node_modules,.venv, build cache, and so on. Runnpm installacross five worktrees and your disk fills up fast. This is the cost that bites first. - Folder cleanup. You have to actually remove worktrees when you are done (
git worktree remove), or your parent directory turns into a graveyard. Tools that manage worktrees for you handle this; if you live in the terminal, it is on you. .gitignoreif you nest them. If you create worktree folders inside your main repo, add them to.gitignoreso you do not accidentally track them. Cleaner option: put them outside the repo entirely, which most tools do by default.- One branch, one worktree. Git will not let you check out the same branch in two worktrees at once. This is on purpose, to stop two folders from corrupting the same branch state. If you need the same branch in two places, branch off it.
Put worktrees in a sibling directory, not inside the repo. A layout like project/, project-hotfix/, project-agent-1/ keeps .gitignore simple and makes cleanup obvious. Some teams keep a dedicated ~/worktrees/ directory and point everything there.
A workflow that actually works#
Here is the setup I would recommend if you are running agents in parallel and want to stay sane:
# main checkout stays clean; you read and review here
cd ~/code/myapp
# one worktree per parallel task or agent session
git worktree add ../myapp-feature-a -b feature-a main
git worktree add ../myapp-feature-b -b feature-b main
# point each agent at its own folder, then review diffs from main
git worktree list
# when a branch merges, tear its folder down
git worktree remove ../myapp-feature-aThe mental model that makes this click: your main checkout becomes the place you read, review, and coordinate, and each worktree is a disposable workspace for one task or one agent. You stop thinking "which branch am I on" and start thinking "which folder is this work in." That maps much better to running several things at once.
So should you use them?#
The honest answer is it depends on how parallel your work actually is. If you do one thing at a time and the branch-and-stash model fits your head, worktrees are a solution to a problem you do not have, and the dependency duplication is just overhead. Do not adopt them because they are trendy.
But if you are running multiple agent sessions, or you are constantly yanked between a feature and a hotfix, worktrees remove a tax you have been quietly paying for years. That is most people doing AI-assisted development in 2026, which is exactly why a 2015 feature is suddenly everywhere. Try one the next time an urgent bug interrupts a feature, and notice that your feature window never had to move. That moment is usually when it clicks.

Folarin Akinloye is an AI Engineer based in London, UK. He builds production-ready agentic AI systems, multi-agent architectures, and sophisticated RAG implementations, and writes about the engineering decisions behind them.