Abstract

I use Git worktrees to run multiple coding agents in parallel in the same repository. Each agent gets its own branch and directory, so they do not overwrite each other’s files. In this tutorial, I share the workflow I use, the commands, and the tradeoffs that matter in practice.

The problem

Most projects have several open issues at once. If I try to solve more than one issue from a single working directory, I spend time stashing changes, switching branches, and resolving avoidable conflicts.

The question is simple:

How do I work on multiple issues in parallel without stepping on my own changes?

For me, the most reliable answer is git worktree.

About git worktrees

git worktree lets you check out multiple branches from one repository at the same time. All worktrees share the same .git object database, so you avoid extra clones and save disk space.

Keep this mental map:

project/
  main                  # Main working directory with the shared .git data
  feature-branch        # Linked working directory for one branch
  fix-issue-branch      # Linked working directory for another branch
  ...

Agent orchestration

I usually run one high-reasoning agent as coordinator and several mid-reasoning agents for implementation tasks.

The coordinator does three things:

1. It assigns focused tasks.
2. It reviews the resulting diffs.
3. It decides when each branch is ready for a pull request.

The downsides

This setup is effective, but not perfect.

Agents still miss instructions at times, even when the right skills are loaded. In complex tasks, they can drift from repository conventions or skip workflow steps such as review or pull request preparation.

Because of that, I treat agent output as a draft that needs supervision, not as something I merge blindly.

A note on tmux

If you use tmux, you can keep one session per repository and one pane per worktree. That makes it practical to work on multiple issues, and even multiple projects, without losing context.