If you have been using AI coding assistants seriously, running multiple chat sessions on different features at the same time, you have probably hit a wall. Not because of the AI. Because of Git.
The problem is the setup. Multiple agent sessions, but still one working directory, one checked-out branch, one pile of local changes. This has worked fine for years in a team without agent sessions. Once several conversations are running in parallel, that single folder becomes a shared resource all of them are fighting over.
The issue is not that the agent cannot code. The issue is that four active lines of work are trying to borrow the same folder.
That is when git worktree started making sense to me. Not as a Git trick. As a way to give each conversation its own place to work.
The short version
git worktree is exactly how you should run one project, many chats, one feature per chat.
Before:
one repo one folder many branches fighting for that folder
After:
one repo many folders one branch per folder
That is the whole shift. Once you start thinking this way, a lot of the weirdness around multi-chat development disappears.
If that clicks, the next section explains how it works under the hood. If you just want to set it up, jump to A concrete setup
How worktrees actually work
A worktree is not a second clone. It is another working directory attached to the same Git repository. That means you can have multiple local folders, each checked out to a different branch, without duplicating the whole repo.
Think of it like this:
repository ├── worktree A -> feat/search-ui ├── worktree B -> feat/editor-flow ├── worktree C -> feat/ci-hardening └── worktree D -> release/1.4
Each folder has its own files, its own branch, and its own uncommitted state. That is the part that matters for agents. One active conversation can stay inside one worktree. It does not need to keep borrowing the same local folder from some other branch.
Why the old way starts feeling cramped
Without worktrees, multi-chat development usually falls into one of a few familiar patterns.
One checkout, constant branch switching
This works fine for a long time. Most of us are used to it. Then the overhead starts showing up: you switch branches to continue another conversation, the working tree is dirty, you stash or partially commit, you come back later and reconstruct context from diffs.
This is usually described as a Git problem. I do not think it is, at least not first. It is a context problem. The repository is trying to host several active threads in one place.
One checkout, lots of local dirt
This is the more dangerous version because it feels normal. Instead of switching cleanly, the checkout just accumulates state. A few unfinished edits here. A half-done experiment there. Some docs from another feature. Maybe a test fix that belongs on a different branch.
In a human-only workflow, experienced engineers can survive this for a while because they carry the context in their head. In an agentic workflow, that starts getting expensive. The filesystem is no longer just a folder on disk. It is part of the context the next conversation is reading.
Stash and pop, until that stops scaling
I do not mean this as an attack on git stash. It has saved a lot of people, including me. Stash worked for years because it let one checkout pretend to be many. And now that LLMs are getting good at helping with rebases, conflicts, and commit cleanup, it is easy to keep stretching that model further than we should.
But none of that changes the underlying reality. You still have one folder. You still have one pile of changes. You are just getting better help while moving that state around. That is useful. It is not the same thing as isolation.
At some point, you stop needing a smarter stash habit and start needing a different workspace model.
The real unit of isolation
This was the shift that made the rest obvious to me. In agent-led development, the useful unit of isolation is not the whole repository. It is the active feature thread.
That thread has a branch, a set of local changes, a way to test that it works, and one active conversation driving it.
Once you look at it that way, the worktree model stops feeling clever and starts feeling obvious.
One meaningful branch gets one worktree. One worktree gets one active conversation.
How this maps to a real branching setup
If your team uses feature branches and release branches, a clean operating model looks like this:
main production history release/x.y integration branch for a train feat/> /> one feature branch, one worktree, one chat hotfix/x.y.z urgent production fix
And locally:
one repo many worktrees one branch per worktree one chat per worktree
That keeps the local model aligned with the integration model.
A concrete setup
This is a working example. The paths are illustrative but the commands are real.
Suppose the main repository lives here:
/Users/you/project
Create a parent directory for worktrees:
mkdir -p /Users/you/project-worktrees
Cut a release branch if you are working in trains:
cd /Users/you/project git checkout main git pull git checkout -b release/1.4 git push -u origin release/1.4
Now create one worktree per active slice:
git -C /Users/you/project worktree add /Users/you/project-worktrees/release-1-4 release/1.4 git -C /Users/you/project worktree add /Users/you/project-worktrees/search-ui -b feat/platform/search-ui release/1.4 git -C /Users/you/project worktree add /Users/you/project-worktrees/editor-flow -b feat/platform/editor-flow release/1.4 git -C /Users/you/project worktree add /Users/you/project-worktrees/ci-hardening -b feat/platform/ci-hardening release/1.4
Now the layout is explicit:
/Users/you/project-worktrees/release-1-4 /Users/you/project-worktrees/search-ui /Users/you/project-worktrees/editor-flow /Users/you/project-worktrees/ci-hardening
At that point the rule is simple: one chat = one worktree path.
Why this fits CI and release trains well
A good delivery system wants each feature branch to prove one coherent slice of work. If your team uses a release branch (an integration branch that batches features before they go to production), worktrees slot in cleanly.
A typical flow looks like this:
Cut a feature branch in its own worktree.
Let one agent conversation work inside that worktree.
Run local checks in that worktree.
Raise a PR from that branch.
Merge the branch into release/x.y when the slice is proven.
Run grouped validation on the release branch.
Promote the release branch later.
This matters because worktrees solve the problem of parallel local work stepping on itself, while the release branch solves the integration problem.
Rules worth keeping
1. Do not use the same worktree for unrelated changes
If a worktree carries a search refactor, a documentation rewrite, and a CI experiment at the same time, it has already lost most of its value. The point of the worktree is to keep one line of work legible.
2. Do not point multiple active feature chats at the same folder
This is the easiest way to reintroduce ambiguity. If two conversations are both editing the same filesystem state for different purposes, you are back in the same failure mode as a single shared checkout.
3. Do not use the same branch in multiple active worktrees
That usually creates more confusion than flexibility. One active branch should have one active local home.
4. Merge or rebase from the release branch periodically
If a release train is active, feature worktrees should pull in changes from the integration branch on purpose, not by accident at the end.
cd /Users/you/project-worktrees/search-ui git fetch origin git rebase origin/release/1.4
That keeps the branch honest against the train it is meant to join.
5. Handoffs should describe the worktree, not just the branch
This matters more than it sounds. A useful handoff includes the worktree path, branch name, objective, files touched, verification status, and known blockers.
For example:
Worktree : /Users/you/project-worktrees/editor-flow Branch : feat/platform/editor-flow Objective : analyst editing workflow for records Touched : frontend edit flow, backend mutation handlers, docs Status : lint green, tests green, local CI pending Blocker : waiting on enum finalization
That is enough for another chat or engineer to resume work without guessing.
Related: Handoffs and context continuity matter even more when things go wrong. See how one misconfigured Postgres parameter stalled replication for 3 weeks and what the team had to reconstruct from scratch.
Useful commands
List worktrees:
git worktree list
Remove a finished worktree:
git worktree remove /Users/you/project-worktrees/search-ui git branch -d feat/platform/search-ui
If the branch was pushed and is no longer needed:
git push origin --delete feat/platform/search-ui
Where worktrees help most with agents
The value is not only cleaner Git. The bigger value is cleaner context. A dedicated worktree gives you that: the visible diffs belong to one branch, the uncommitted files belong to one slice, the verification state belongs to one feature, and the agent is less likely to read changes that have nothing to do with the feature it is working on.
That is why worktrees are turning out to be useful in agentic coding patterns. They reduce accidental context sharing. This is not a prompt engineering trick. It is a workspace design decision.
Start small
If you want to adopt this without changing everything at once, do just this:
Create a
project-worktrees/folder next to your repo.Keep one integration branch worktree there.
Create one worktree per active feature branch.
Run one chat per worktree.
That is enough to tell very quickly whether your current workflow has outgrown a single checkout. For most teams using agents seriously, it usually has.
It is a small change to how you organize folders, but it changes how cleanly parallel work actually lands.
If your team is scaling up agent-assisted development and hitting workflow friction beyond just Git, talk to us at One2N. We have set this up across multiple client teams and can help you get there faster.
If you have been using AI coding assistants seriously, running multiple chat sessions on different features at the same time, you have probably hit a wall. Not because of the AI. Because of Git.
The problem is the setup. Multiple agent sessions, but still one working directory, one checked-out branch, one pile of local changes. This has worked fine for years in a team without agent sessions. Once several conversations are running in parallel, that single folder becomes a shared resource all of them are fighting over.
The issue is not that the agent cannot code. The issue is that four active lines of work are trying to borrow the same folder.
That is when git worktree started making sense to me. Not as a Git trick. As a way to give each conversation its own place to work.
The short version
git worktree is exactly how you should run one project, many chats, one feature per chat.
Before:
one repo one folder many branches fighting for that folder
After:
one repo many folders one branch per folder
That is the whole shift. Once you start thinking this way, a lot of the weirdness around multi-chat development disappears.
If that clicks, the next section explains how it works under the hood. If you just want to set it up, jump to A concrete setup
How worktrees actually work
A worktree is not a second clone. It is another working directory attached to the same Git repository. That means you can have multiple local folders, each checked out to a different branch, without duplicating the whole repo.
Think of it like this:
repository ├── worktree A -> feat/search-ui ├── worktree B -> feat/editor-flow ├── worktree C -> feat/ci-hardening └── worktree D -> release/1.4
Each folder has its own files, its own branch, and its own uncommitted state. That is the part that matters for agents. One active conversation can stay inside one worktree. It does not need to keep borrowing the same local folder from some other branch.
Why the old way starts feeling cramped
Without worktrees, multi-chat development usually falls into one of a few familiar patterns.
One checkout, constant branch switching
This works fine for a long time. Most of us are used to it. Then the overhead starts showing up: you switch branches to continue another conversation, the working tree is dirty, you stash or partially commit, you come back later and reconstruct context from diffs.
This is usually described as a Git problem. I do not think it is, at least not first. It is a context problem. The repository is trying to host several active threads in one place.
One checkout, lots of local dirt
This is the more dangerous version because it feels normal. Instead of switching cleanly, the checkout just accumulates state. A few unfinished edits here. A half-done experiment there. Some docs from another feature. Maybe a test fix that belongs on a different branch.
In a human-only workflow, experienced engineers can survive this for a while because they carry the context in their head. In an agentic workflow, that starts getting expensive. The filesystem is no longer just a folder on disk. It is part of the context the next conversation is reading.
Stash and pop, until that stops scaling
I do not mean this as an attack on git stash. It has saved a lot of people, including me. Stash worked for years because it let one checkout pretend to be many. And now that LLMs are getting good at helping with rebases, conflicts, and commit cleanup, it is easy to keep stretching that model further than we should.
But none of that changes the underlying reality. You still have one folder. You still have one pile of changes. You are just getting better help while moving that state around. That is useful. It is not the same thing as isolation.
At some point, you stop needing a smarter stash habit and start needing a different workspace model.
The real unit of isolation
This was the shift that made the rest obvious to me. In agent-led development, the useful unit of isolation is not the whole repository. It is the active feature thread.
That thread has a branch, a set of local changes, a way to test that it works, and one active conversation driving it.
Once you look at it that way, the worktree model stops feeling clever and starts feeling obvious.
One meaningful branch gets one worktree. One worktree gets one active conversation.
How this maps to a real branching setup
If your team uses feature branches and release branches, a clean operating model looks like this:
main production history release/x.y integration branch for a train feat/> /> one feature branch, one worktree, one chat hotfix/x.y.z urgent production fix
And locally:
one repo many worktrees one branch per worktree one chat per worktree
That keeps the local model aligned with the integration model.
A concrete setup
This is a working example. The paths are illustrative but the commands are real.
Suppose the main repository lives here:
/Users/you/project
Create a parent directory for worktrees:
mkdir -p /Users/you/project-worktrees
Cut a release branch if you are working in trains:
cd /Users/you/project git checkout main git pull git checkout -b release/1.4 git push -u origin release/1.4
Now create one worktree per active slice:
git -C /Users/you/project worktree add /Users/you/project-worktrees/release-1-4 release/1.4 git -C /Users/you/project worktree add /Users/you/project-worktrees/search-ui -b feat/platform/search-ui release/1.4 git -C /Users/you/project worktree add /Users/you/project-worktrees/editor-flow -b feat/platform/editor-flow release/1.4 git -C /Users/you/project worktree add /Users/you/project-worktrees/ci-hardening -b feat/platform/ci-hardening release/1.4
Now the layout is explicit:
/Users/you/project-worktrees/release-1-4 /Users/you/project-worktrees/search-ui /Users/you/project-worktrees/editor-flow /Users/you/project-worktrees/ci-hardening
At that point the rule is simple: one chat = one worktree path.
Why this fits CI and release trains well
A good delivery system wants each feature branch to prove one coherent slice of work. If your team uses a release branch (an integration branch that batches features before they go to production), worktrees slot in cleanly.
A typical flow looks like this:
Cut a feature branch in its own worktree.
Let one agent conversation work inside that worktree.
Run local checks in that worktree.
Raise a PR from that branch.
Merge the branch into release/x.y when the slice is proven.
Run grouped validation on the release branch.
Promote the release branch later.
This matters because worktrees solve the problem of parallel local work stepping on itself, while the release branch solves the integration problem.
Rules worth keeping
1. Do not use the same worktree for unrelated changes
If a worktree carries a search refactor, a documentation rewrite, and a CI experiment at the same time, it has already lost most of its value. The point of the worktree is to keep one line of work legible.
2. Do not point multiple active feature chats at the same folder
This is the easiest way to reintroduce ambiguity. If two conversations are both editing the same filesystem state for different purposes, you are back in the same failure mode as a single shared checkout.
3. Do not use the same branch in multiple active worktrees
That usually creates more confusion than flexibility. One active branch should have one active local home.
4. Merge or rebase from the release branch periodically
If a release train is active, feature worktrees should pull in changes from the integration branch on purpose, not by accident at the end.
cd /Users/you/project-worktrees/search-ui git fetch origin git rebase origin/release/1.4
That keeps the branch honest against the train it is meant to join.
5. Handoffs should describe the worktree, not just the branch
This matters more than it sounds. A useful handoff includes the worktree path, branch name, objective, files touched, verification status, and known blockers.
For example:
Worktree : /Users/you/project-worktrees/editor-flow Branch : feat/platform/editor-flow Objective : analyst editing workflow for records Touched : frontend edit flow, backend mutation handlers, docs Status : lint green, tests green, local CI pending Blocker : waiting on enum finalization
That is enough for another chat or engineer to resume work without guessing.
Related: Handoffs and context continuity matter even more when things go wrong. See how one misconfigured Postgres parameter stalled replication for 3 weeks and what the team had to reconstruct from scratch.
Useful commands
List worktrees:
git worktree list
Remove a finished worktree:
git worktree remove /Users/you/project-worktrees/search-ui git branch -d feat/platform/search-ui
If the branch was pushed and is no longer needed:
git push origin --delete feat/platform/search-ui
Where worktrees help most with agents
The value is not only cleaner Git. The bigger value is cleaner context. A dedicated worktree gives you that: the visible diffs belong to one branch, the uncommitted files belong to one slice, the verification state belongs to one feature, and the agent is less likely to read changes that have nothing to do with the feature it is working on.
That is why worktrees are turning out to be useful in agentic coding patterns. They reduce accidental context sharing. This is not a prompt engineering trick. It is a workspace design decision.
Start small
If you want to adopt this without changing everything at once, do just this:
Create a
project-worktrees/folder next to your repo.Keep one integration branch worktree there.
Create one worktree per active feature branch.
Run one chat per worktree.
That is enough to tell very quickly whether your current workflow has outgrown a single checkout. For most teams using agents seriously, it usually has.
It is a small change to how you organize folders, but it changes how cleanly parallel work actually lands.
If your team is scaling up agent-assisted development and hitting workflow friction beyond just Git, talk to us at One2N. We have set this up across multiple client teams and can help you get there faster.
If you have been using AI coding assistants seriously, running multiple chat sessions on different features at the same time, you have probably hit a wall. Not because of the AI. Because of Git.
The problem is the setup. Multiple agent sessions, but still one working directory, one checked-out branch, one pile of local changes. This has worked fine for years in a team without agent sessions. Once several conversations are running in parallel, that single folder becomes a shared resource all of them are fighting over.
The issue is not that the agent cannot code. The issue is that four active lines of work are trying to borrow the same folder.
That is when git worktree started making sense to me. Not as a Git trick. As a way to give each conversation its own place to work.
The short version
git worktree is exactly how you should run one project, many chats, one feature per chat.
Before:
one repo one folder many branches fighting for that folder
After:
one repo many folders one branch per folder
That is the whole shift. Once you start thinking this way, a lot of the weirdness around multi-chat development disappears.
If that clicks, the next section explains how it works under the hood. If you just want to set it up, jump to A concrete setup
How worktrees actually work
A worktree is not a second clone. It is another working directory attached to the same Git repository. That means you can have multiple local folders, each checked out to a different branch, without duplicating the whole repo.
Think of it like this:
repository ├── worktree A -> feat/search-ui ├── worktree B -> feat/editor-flow ├── worktree C -> feat/ci-hardening └── worktree D -> release/1.4
Each folder has its own files, its own branch, and its own uncommitted state. That is the part that matters for agents. One active conversation can stay inside one worktree. It does not need to keep borrowing the same local folder from some other branch.
Why the old way starts feeling cramped
Without worktrees, multi-chat development usually falls into one of a few familiar patterns.
One checkout, constant branch switching
This works fine for a long time. Most of us are used to it. Then the overhead starts showing up: you switch branches to continue another conversation, the working tree is dirty, you stash or partially commit, you come back later and reconstruct context from diffs.
This is usually described as a Git problem. I do not think it is, at least not first. It is a context problem. The repository is trying to host several active threads in one place.
One checkout, lots of local dirt
This is the more dangerous version because it feels normal. Instead of switching cleanly, the checkout just accumulates state. A few unfinished edits here. A half-done experiment there. Some docs from another feature. Maybe a test fix that belongs on a different branch.
In a human-only workflow, experienced engineers can survive this for a while because they carry the context in their head. In an agentic workflow, that starts getting expensive. The filesystem is no longer just a folder on disk. It is part of the context the next conversation is reading.
Stash and pop, until that stops scaling
I do not mean this as an attack on git stash. It has saved a lot of people, including me. Stash worked for years because it let one checkout pretend to be many. And now that LLMs are getting good at helping with rebases, conflicts, and commit cleanup, it is easy to keep stretching that model further than we should.
But none of that changes the underlying reality. You still have one folder. You still have one pile of changes. You are just getting better help while moving that state around. That is useful. It is not the same thing as isolation.
At some point, you stop needing a smarter stash habit and start needing a different workspace model.
The real unit of isolation
This was the shift that made the rest obvious to me. In agent-led development, the useful unit of isolation is not the whole repository. It is the active feature thread.
That thread has a branch, a set of local changes, a way to test that it works, and one active conversation driving it.
Once you look at it that way, the worktree model stops feeling clever and starts feeling obvious.
One meaningful branch gets one worktree. One worktree gets one active conversation.
How this maps to a real branching setup
If your team uses feature branches and release branches, a clean operating model looks like this:
main production history release/x.y integration branch for a train feat/> /> one feature branch, one worktree, one chat hotfix/x.y.z urgent production fix
And locally:
one repo many worktrees one branch per worktree one chat per worktree
That keeps the local model aligned with the integration model.
A concrete setup
This is a working example. The paths are illustrative but the commands are real.
Suppose the main repository lives here:
/Users/you/project
Create a parent directory for worktrees:
mkdir -p /Users/you/project-worktrees
Cut a release branch if you are working in trains:
cd /Users/you/project git checkout main git pull git checkout -b release/1.4 git push -u origin release/1.4
Now create one worktree per active slice:
git -C /Users/you/project worktree add /Users/you/project-worktrees/release-1-4 release/1.4 git -C /Users/you/project worktree add /Users/you/project-worktrees/search-ui -b feat/platform/search-ui release/1.4 git -C /Users/you/project worktree add /Users/you/project-worktrees/editor-flow -b feat/platform/editor-flow release/1.4 git -C /Users/you/project worktree add /Users/you/project-worktrees/ci-hardening -b feat/platform/ci-hardening release/1.4
Now the layout is explicit:
/Users/you/project-worktrees/release-1-4 /Users/you/project-worktrees/search-ui /Users/you/project-worktrees/editor-flow /Users/you/project-worktrees/ci-hardening
At that point the rule is simple: one chat = one worktree path.
Why this fits CI and release trains well
A good delivery system wants each feature branch to prove one coherent slice of work. If your team uses a release branch (an integration branch that batches features before they go to production), worktrees slot in cleanly.
A typical flow looks like this:
Cut a feature branch in its own worktree.
Let one agent conversation work inside that worktree.
Run local checks in that worktree.
Raise a PR from that branch.
Merge the branch into release/x.y when the slice is proven.
Run grouped validation on the release branch.
Promote the release branch later.
This matters because worktrees solve the problem of parallel local work stepping on itself, while the release branch solves the integration problem.
Rules worth keeping
1. Do not use the same worktree for unrelated changes
If a worktree carries a search refactor, a documentation rewrite, and a CI experiment at the same time, it has already lost most of its value. The point of the worktree is to keep one line of work legible.
2. Do not point multiple active feature chats at the same folder
This is the easiest way to reintroduce ambiguity. If two conversations are both editing the same filesystem state for different purposes, you are back in the same failure mode as a single shared checkout.
3. Do not use the same branch in multiple active worktrees
That usually creates more confusion than flexibility. One active branch should have one active local home.
4. Merge or rebase from the release branch periodically
If a release train is active, feature worktrees should pull in changes from the integration branch on purpose, not by accident at the end.
cd /Users/you/project-worktrees/search-ui git fetch origin git rebase origin/release/1.4
That keeps the branch honest against the train it is meant to join.
5. Handoffs should describe the worktree, not just the branch
This matters more than it sounds. A useful handoff includes the worktree path, branch name, objective, files touched, verification status, and known blockers.
For example:
Worktree : /Users/you/project-worktrees/editor-flow Branch : feat/platform/editor-flow Objective : analyst editing workflow for records Touched : frontend edit flow, backend mutation handlers, docs Status : lint green, tests green, local CI pending Blocker : waiting on enum finalization
That is enough for another chat or engineer to resume work without guessing.
Related: Handoffs and context continuity matter even more when things go wrong. See how one misconfigured Postgres parameter stalled replication for 3 weeks and what the team had to reconstruct from scratch.
Useful commands
List worktrees:
git worktree list
Remove a finished worktree:
git worktree remove /Users/you/project-worktrees/search-ui git branch -d feat/platform/search-ui
If the branch was pushed and is no longer needed:
git push origin --delete feat/platform/search-ui
Where worktrees help most with agents
The value is not only cleaner Git. The bigger value is cleaner context. A dedicated worktree gives you that: the visible diffs belong to one branch, the uncommitted files belong to one slice, the verification state belongs to one feature, and the agent is less likely to read changes that have nothing to do with the feature it is working on.
That is why worktrees are turning out to be useful in agentic coding patterns. They reduce accidental context sharing. This is not a prompt engineering trick. It is a workspace design decision.
Start small
If you want to adopt this without changing everything at once, do just this:
Create a
project-worktrees/folder next to your repo.Keep one integration branch worktree there.
Create one worktree per active feature branch.
Run one chat per worktree.
That is enough to tell very quickly whether your current workflow has outgrown a single checkout. For most teams using agents seriously, it usually has.
It is a small change to how you organize folders, but it changes how cleanly parallel work actually lands.
If your team is scaling up agent-assisted development and hitting workflow friction beyond just Git, talk to us at One2N. We have set this up across multiple client teams and can help you get there faster.
If you have been using AI coding assistants seriously, running multiple chat sessions on different features at the same time, you have probably hit a wall. Not because of the AI. Because of Git.
The problem is the setup. Multiple agent sessions, but still one working directory, one checked-out branch, one pile of local changes. This has worked fine for years in a team without agent sessions. Once several conversations are running in parallel, that single folder becomes a shared resource all of them are fighting over.
The issue is not that the agent cannot code. The issue is that four active lines of work are trying to borrow the same folder.
That is when git worktree started making sense to me. Not as a Git trick. As a way to give each conversation its own place to work.
The short version
git worktree is exactly how you should run one project, many chats, one feature per chat.
Before:
one repo one folder many branches fighting for that folder
After:
one repo many folders one branch per folder
That is the whole shift. Once you start thinking this way, a lot of the weirdness around multi-chat development disappears.
If that clicks, the next section explains how it works under the hood. If you just want to set it up, jump to A concrete setup
How worktrees actually work
A worktree is not a second clone. It is another working directory attached to the same Git repository. That means you can have multiple local folders, each checked out to a different branch, without duplicating the whole repo.
Think of it like this:
repository ├── worktree A -> feat/search-ui ├── worktree B -> feat/editor-flow ├── worktree C -> feat/ci-hardening └── worktree D -> release/1.4
Each folder has its own files, its own branch, and its own uncommitted state. That is the part that matters for agents. One active conversation can stay inside one worktree. It does not need to keep borrowing the same local folder from some other branch.
Why the old way starts feeling cramped
Without worktrees, multi-chat development usually falls into one of a few familiar patterns.
One checkout, constant branch switching
This works fine for a long time. Most of us are used to it. Then the overhead starts showing up: you switch branches to continue another conversation, the working tree is dirty, you stash or partially commit, you come back later and reconstruct context from diffs.
This is usually described as a Git problem. I do not think it is, at least not first. It is a context problem. The repository is trying to host several active threads in one place.
One checkout, lots of local dirt
This is the more dangerous version because it feels normal. Instead of switching cleanly, the checkout just accumulates state. A few unfinished edits here. A half-done experiment there. Some docs from another feature. Maybe a test fix that belongs on a different branch.
In a human-only workflow, experienced engineers can survive this for a while because they carry the context in their head. In an agentic workflow, that starts getting expensive. The filesystem is no longer just a folder on disk. It is part of the context the next conversation is reading.
Stash and pop, until that stops scaling
I do not mean this as an attack on git stash. It has saved a lot of people, including me. Stash worked for years because it let one checkout pretend to be many. And now that LLMs are getting good at helping with rebases, conflicts, and commit cleanup, it is easy to keep stretching that model further than we should.
But none of that changes the underlying reality. You still have one folder. You still have one pile of changes. You are just getting better help while moving that state around. That is useful. It is not the same thing as isolation.
At some point, you stop needing a smarter stash habit and start needing a different workspace model.
The real unit of isolation
This was the shift that made the rest obvious to me. In agent-led development, the useful unit of isolation is not the whole repository. It is the active feature thread.
That thread has a branch, a set of local changes, a way to test that it works, and one active conversation driving it.
Once you look at it that way, the worktree model stops feeling clever and starts feeling obvious.
One meaningful branch gets one worktree. One worktree gets one active conversation.
How this maps to a real branching setup
If your team uses feature branches and release branches, a clean operating model looks like this:
main production history release/x.y integration branch for a train feat/> /> one feature branch, one worktree, one chat hotfix/x.y.z urgent production fix
And locally:
one repo many worktrees one branch per worktree one chat per worktree
That keeps the local model aligned with the integration model.
A concrete setup
This is a working example. The paths are illustrative but the commands are real.
Suppose the main repository lives here:
/Users/you/project
Create a parent directory for worktrees:
mkdir -p /Users/you/project-worktrees
Cut a release branch if you are working in trains:
cd /Users/you/project git checkout main git pull git checkout -b release/1.4 git push -u origin release/1.4
Now create one worktree per active slice:
git -C /Users/you/project worktree add /Users/you/project-worktrees/release-1-4 release/1.4 git -C /Users/you/project worktree add /Users/you/project-worktrees/search-ui -b feat/platform/search-ui release/1.4 git -C /Users/you/project worktree add /Users/you/project-worktrees/editor-flow -b feat/platform/editor-flow release/1.4 git -C /Users/you/project worktree add /Users/you/project-worktrees/ci-hardening -b feat/platform/ci-hardening release/1.4
Now the layout is explicit:
/Users/you/project-worktrees/release-1-4 /Users/you/project-worktrees/search-ui /Users/you/project-worktrees/editor-flow /Users/you/project-worktrees/ci-hardening
At that point the rule is simple: one chat = one worktree path.
Why this fits CI and release trains well
A good delivery system wants each feature branch to prove one coherent slice of work. If your team uses a release branch (an integration branch that batches features before they go to production), worktrees slot in cleanly.
A typical flow looks like this:
Cut a feature branch in its own worktree.
Let one agent conversation work inside that worktree.
Run local checks in that worktree.
Raise a PR from that branch.
Merge the branch into release/x.y when the slice is proven.
Run grouped validation on the release branch.
Promote the release branch later.
This matters because worktrees solve the problem of parallel local work stepping on itself, while the release branch solves the integration problem.
Rules worth keeping
1. Do not use the same worktree for unrelated changes
If a worktree carries a search refactor, a documentation rewrite, and a CI experiment at the same time, it has already lost most of its value. The point of the worktree is to keep one line of work legible.
2. Do not point multiple active feature chats at the same folder
This is the easiest way to reintroduce ambiguity. If two conversations are both editing the same filesystem state for different purposes, you are back in the same failure mode as a single shared checkout.
3. Do not use the same branch in multiple active worktrees
That usually creates more confusion than flexibility. One active branch should have one active local home.
4. Merge or rebase from the release branch periodically
If a release train is active, feature worktrees should pull in changes from the integration branch on purpose, not by accident at the end.
cd /Users/you/project-worktrees/search-ui git fetch origin git rebase origin/release/1.4
That keeps the branch honest against the train it is meant to join.
5. Handoffs should describe the worktree, not just the branch
This matters more than it sounds. A useful handoff includes the worktree path, branch name, objective, files touched, verification status, and known blockers.
For example:
Worktree : /Users/you/project-worktrees/editor-flow Branch : feat/platform/editor-flow Objective : analyst editing workflow for records Touched : frontend edit flow, backend mutation handlers, docs Status : lint green, tests green, local CI pending Blocker : waiting on enum finalization
That is enough for another chat or engineer to resume work without guessing.
Related: Handoffs and context continuity matter even more when things go wrong. See how one misconfigured Postgres parameter stalled replication for 3 weeks and what the team had to reconstruct from scratch.
Useful commands
List worktrees:
git worktree list
Remove a finished worktree:
git worktree remove /Users/you/project-worktrees/search-ui git branch -d feat/platform/search-ui
If the branch was pushed and is no longer needed:
git push origin --delete feat/platform/search-ui
Where worktrees help most with agents
The value is not only cleaner Git. The bigger value is cleaner context. A dedicated worktree gives you that: the visible diffs belong to one branch, the uncommitted files belong to one slice, the verification state belongs to one feature, and the agent is less likely to read changes that have nothing to do with the feature it is working on.
That is why worktrees are turning out to be useful in agentic coding patterns. They reduce accidental context sharing. This is not a prompt engineering trick. It is a workspace design decision.
Start small
If you want to adopt this without changing everything at once, do just this:
Create a
project-worktrees/folder next to your repo.Keep one integration branch worktree there.
Create one worktree per active feature branch.
Run one chat per worktree.
That is enough to tell very quickly whether your current workflow has outgrown a single checkout. For most teams using agents seriously, it usually has.
It is a small change to how you organize folders, but it changes how cleanly parallel work actually lands.
If your team is scaling up agent-assisted development and hitting workflow friction beyond just Git, talk to us at One2N. We have set this up across multiple client teams and can help you get there faster.
If you have been using AI coding assistants seriously, running multiple chat sessions on different features at the same time, you have probably hit a wall. Not because of the AI. Because of Git.
The problem is the setup. Multiple agent sessions, but still one working directory, one checked-out branch, one pile of local changes. This has worked fine for years in a team without agent sessions. Once several conversations are running in parallel, that single folder becomes a shared resource all of them are fighting over.
The issue is not that the agent cannot code. The issue is that four active lines of work are trying to borrow the same folder.
That is when git worktree started making sense to me. Not as a Git trick. As a way to give each conversation its own place to work.
The short version
git worktree is exactly how you should run one project, many chats, one feature per chat.
Before:
one repo one folder many branches fighting for that folder
After:
one repo many folders one branch per folder
That is the whole shift. Once you start thinking this way, a lot of the weirdness around multi-chat development disappears.
If that clicks, the next section explains how it works under the hood. If you just want to set it up, jump to A concrete setup
How worktrees actually work
A worktree is not a second clone. It is another working directory attached to the same Git repository. That means you can have multiple local folders, each checked out to a different branch, without duplicating the whole repo.
Think of it like this:
repository ├── worktree A -> feat/search-ui ├── worktree B -> feat/editor-flow ├── worktree C -> feat/ci-hardening └── worktree D -> release/1.4
Each folder has its own files, its own branch, and its own uncommitted state. That is the part that matters for agents. One active conversation can stay inside one worktree. It does not need to keep borrowing the same local folder from some other branch.
Why the old way starts feeling cramped
Without worktrees, multi-chat development usually falls into one of a few familiar patterns.
One checkout, constant branch switching
This works fine for a long time. Most of us are used to it. Then the overhead starts showing up: you switch branches to continue another conversation, the working tree is dirty, you stash or partially commit, you come back later and reconstruct context from diffs.
This is usually described as a Git problem. I do not think it is, at least not first. It is a context problem. The repository is trying to host several active threads in one place.
One checkout, lots of local dirt
This is the more dangerous version because it feels normal. Instead of switching cleanly, the checkout just accumulates state. A few unfinished edits here. A half-done experiment there. Some docs from another feature. Maybe a test fix that belongs on a different branch.
In a human-only workflow, experienced engineers can survive this for a while because they carry the context in their head. In an agentic workflow, that starts getting expensive. The filesystem is no longer just a folder on disk. It is part of the context the next conversation is reading.
Stash and pop, until that stops scaling
I do not mean this as an attack on git stash. It has saved a lot of people, including me. Stash worked for years because it let one checkout pretend to be many. And now that LLMs are getting good at helping with rebases, conflicts, and commit cleanup, it is easy to keep stretching that model further than we should.
But none of that changes the underlying reality. You still have one folder. You still have one pile of changes. You are just getting better help while moving that state around. That is useful. It is not the same thing as isolation.
At some point, you stop needing a smarter stash habit and start needing a different workspace model.
The real unit of isolation
This was the shift that made the rest obvious to me. In agent-led development, the useful unit of isolation is not the whole repository. It is the active feature thread.
That thread has a branch, a set of local changes, a way to test that it works, and one active conversation driving it.
Once you look at it that way, the worktree model stops feeling clever and starts feeling obvious.
One meaningful branch gets one worktree. One worktree gets one active conversation.
How this maps to a real branching setup
If your team uses feature branches and release branches, a clean operating model looks like this:
main production history release/x.y integration branch for a train feat/> /> one feature branch, one worktree, one chat hotfix/x.y.z urgent production fix
And locally:
one repo many worktrees one branch per worktree one chat per worktree
That keeps the local model aligned with the integration model.
A concrete setup
This is a working example. The paths are illustrative but the commands are real.
Suppose the main repository lives here:
/Users/you/project
Create a parent directory for worktrees:
mkdir -p /Users/you/project-worktrees
Cut a release branch if you are working in trains:
cd /Users/you/project git checkout main git pull git checkout -b release/1.4 git push -u origin release/1.4
Now create one worktree per active slice:
git -C /Users/you/project worktree add /Users/you/project-worktrees/release-1-4 release/1.4 git -C /Users/you/project worktree add /Users/you/project-worktrees/search-ui -b feat/platform/search-ui release/1.4 git -C /Users/you/project worktree add /Users/you/project-worktrees/editor-flow -b feat/platform/editor-flow release/1.4 git -C /Users/you/project worktree add /Users/you/project-worktrees/ci-hardening -b feat/platform/ci-hardening release/1.4
Now the layout is explicit:
/Users/you/project-worktrees/release-1-4 /Users/you/project-worktrees/search-ui /Users/you/project-worktrees/editor-flow /Users/you/project-worktrees/ci-hardening
At that point the rule is simple: one chat = one worktree path.
Why this fits CI and release trains well
A good delivery system wants each feature branch to prove one coherent slice of work. If your team uses a release branch (an integration branch that batches features before they go to production), worktrees slot in cleanly.
A typical flow looks like this:
Cut a feature branch in its own worktree.
Let one agent conversation work inside that worktree.
Run local checks in that worktree.
Raise a PR from that branch.
Merge the branch into release/x.y when the slice is proven.
Run grouped validation on the release branch.
Promote the release branch later.
This matters because worktrees solve the problem of parallel local work stepping on itself, while the release branch solves the integration problem.
Rules worth keeping
1. Do not use the same worktree for unrelated changes
If a worktree carries a search refactor, a documentation rewrite, and a CI experiment at the same time, it has already lost most of its value. The point of the worktree is to keep one line of work legible.
2. Do not point multiple active feature chats at the same folder
This is the easiest way to reintroduce ambiguity. If two conversations are both editing the same filesystem state for different purposes, you are back in the same failure mode as a single shared checkout.
3. Do not use the same branch in multiple active worktrees
That usually creates more confusion than flexibility. One active branch should have one active local home.
4. Merge or rebase from the release branch periodically
If a release train is active, feature worktrees should pull in changes from the integration branch on purpose, not by accident at the end.
cd /Users/you/project-worktrees/search-ui git fetch origin git rebase origin/release/1.4
That keeps the branch honest against the train it is meant to join.
5. Handoffs should describe the worktree, not just the branch
This matters more than it sounds. A useful handoff includes the worktree path, branch name, objective, files touched, verification status, and known blockers.
For example:
Worktree : /Users/you/project-worktrees/editor-flow Branch : feat/platform/editor-flow Objective : analyst editing workflow for records Touched : frontend edit flow, backend mutation handlers, docs Status : lint green, tests green, local CI pending Blocker : waiting on enum finalization
That is enough for another chat or engineer to resume work without guessing.
Related: Handoffs and context continuity matter even more when things go wrong. See how one misconfigured Postgres parameter stalled replication for 3 weeks and what the team had to reconstruct from scratch.
Useful commands
List worktrees:
git worktree list
Remove a finished worktree:
git worktree remove /Users/you/project-worktrees/search-ui git branch -d feat/platform/search-ui
If the branch was pushed and is no longer needed:
git push origin --delete feat/platform/search-ui
Where worktrees help most with agents
The value is not only cleaner Git. The bigger value is cleaner context. A dedicated worktree gives you that: the visible diffs belong to one branch, the uncommitted files belong to one slice, the verification state belongs to one feature, and the agent is less likely to read changes that have nothing to do with the feature it is working on.
That is why worktrees are turning out to be useful in agentic coding patterns. They reduce accidental context sharing. This is not a prompt engineering trick. It is a workspace design decision.
Start small
If you want to adopt this without changing everything at once, do just this:
Create a
project-worktrees/folder next to your repo.Keep one integration branch worktree there.
Create one worktree per active feature branch.
Run one chat per worktree.
That is enough to tell very quickly whether your current workflow has outgrown a single checkout. For most teams using agents seriously, it usually has.
It is a small change to how you organize folders, but it changes how cleanly parallel work actually lands.
If your team is scaling up agent-assisted development and hitting workflow friction beyond just Git, talk to us at One2N. We have set this up across multiple client teams and can help you get there faster.
In this post
In this post
Section
Share
Share
In this post
section
Share
Keywords
git worktrees, agentic development, AI coding agents, git worktree tutorial, parallel agent workflows, multi-chat git setup, git worktree vs clone, feature branch isolation, git worktree agentic coding, LLM coding workflow, agentic coding best practices, git parallel branches, release train git workflow, one chat one worktree, AI developer tools, git workspace management, git worktree handoff, concurrent AI development, git branch isolation, developer productivity AI
