One folder, two agents: the work gets mixed
One repo folder used to be enough.
Have a feat/x branch, check it out, work, commit, back to main. Dirty? Stash. Conflict? Finish it first. One person, one tree, done.
Now agents write too. Git didn’t change — a branch is still a branch. What’s different: more than one “hand” can touch files in the same hour.
Git Logo
A branch is a line of work
git branch + checkout is still the usual way to separate what you’re working on.
- clean
main fix/loginfor a bugfeat/exportfor a feature
That’s about where commits go, where the PR comes from, where it merges.
One folder — switching branches swaps the tree
Easy to miss: in a normal single clone, only one branch is “live” in that folder. Checkout swaps the working tree.
An agent is writing under src/, I switch branches — mess. Or the other way: I think the folder is still for task A, but the agent already rewrote half the tree for task B.
Branches separate history. They do not automatically separate workspaces.
Worktree: another folder, same repo
git worktree adds a checkout at a separate path. One repo, several working directories. Each folder can sit on a different branch without overwriting each other’s files.
One .git — many folders, checkouts can run in parallel
Roughly:
# main repo stays at ~/proj (e.g. on main)
git worktree add ../proj-fix-login fix/login
git worktree add ../proj-feat-export -b feat/export main
So:
~/proj— me, or agent A~/proj-fix-login— agent B~/proj-feat-export— agent C
Still one remote. Different folders, different dirty state. node_modules / builds can differ per tree if you install separately.
For me the point is simple: switching tasks doesn’t have to shuffle the folder someone else (or another agent) is using.
Why this only started mattering lately
When work was one human at a time, checkout + stash was fine. Agents are a different story.
They often run together — two chats, a cloud agent, or an agent plus me. A session can run long: lots of files, tests going. The agent also “trusts” the open folder is its own. Flip the tree underneath and you get a mash-up.
Review is nicer from a worktree that only holds one line of work, not a tree mixing three experiments.
There’s still a branch in each worktree. The difference: I don’t have to kick other work off disk just to try a second path.
When a branch alone is enough
One task, one session, sequential. Short agent runs: small change, commit, done. Or I’m fine stashing / committing WIP before I switch.
If the rhythm is still linear, worktrees just get in the way: extra folders, extra installs, and constant “wait, which folder am I in?”
When I reach for a worktree
Agent A on a feature while I (or another agent) need a hotfix on another branch. Risky experiments — big refactor, dependency upgrade — without touching the daily tree. Several Cursor / cloud agents, each pointed at its own path. Or a long change sitting in a folder while I go back to a clean main.
My mental model is simple: one worktree ≈ one agent context / one active PR. The branch inside is still the name I’ll push.
Usual footguns
Each tree may need its own npm install / build — monorepos feel that fast. The same branch also can’t be checked out in two worktrees at once; normal — make a new branch or finish the old one.
Wrong folder is the most common bug: terminal, editor, agent — keep cwd aligned. After merge, git worktree remove; don’t hoard zombie folders.
And a worktree doesn’t replace discipline. Small commits, clear messages, narrow PRs. Parallel folders won’t save a messy PR.
Not “replace branch with worktree”
Branch is still for history and PRs. Worktree is for folders on disk so they don’t fight.
What changed in the agent era is frequency. More than one “worker” touching the repo more often, so you need more than one working tree more often.
If agents are still one-at-a-time and sequential, stick with branches. If you keep colliding in the same folder — try git worktree add.
Comments & Discussion