Git worktrees, without the mystery
A worktree gives a Git repository another working directory. It is useful for parallel tasks, but it is not a container or a security boundary.
On this page
One repository, more than one checkout
A linked worktree has its own checked-out files and working state while sharing the repository's object storage. This lets you work on another branch without repeatedly stashing changes in the original directory.
For coding agents, the benefit is an explicit location for each task's edits. It becomes easier to inspect one task without looking through unrelated working changes.
git worktree list
git status --short
git branch --show-currentWhat is isolated—and what is not
A separate checkout isolates the working files. It does not automatically separate environment variables, credentials, database instances, network ports or external APIs.
If two worktrees run the same development server port or write to the same test database, they can still interfere. Treat resource isolation as a separate design decision.
Use worktrees deliberately
Start from known state
Check existing changes and choose the commit or branch that the new task should use.
Name the task context
Use a meaningful branch and directory so the worktree is recognizable in Git and in your workspace.
Verify independently
Run the relevant checks in that working directory, with the right dependencies and configuration.
Integrate and clean up
Merge through your normal process and inspect uncommitted work before removing an old worktree.
A few good questions
Can worktrees share a branch?
Git normally prevents checking out the same branch in multiple worktrees at once. Use separate task branches for independent work.
Does a worktree protect the host from an agent?
No. The agent's permissions and operating environment determine what it can access.
Read next
See the official Git worktree documentation for command details, and the parallel-work use case for an agent-oriented workflow.