• Context
• Worktrees Workflow
• Setup
• Creating a worktree + branch
• Switching between worktrees
• Merging, rebasing, and cleaning up worktrees
• Conclusion

Context

A look at how Git worktrees have improved my workflows around context switching in general and agentic task concurrency in particular.

Here's the essense of the workflow I've adopted.

Worktrees Workflow

In On working with agentic models > Explore alternative implementations in parallel, I describe a process of making copies of repos in order to perform independent tasks concurrently. The main conceit was that for effective concurrency, sometimes you need multi copies of the code base, not just branches. Turns out, there is a better way of doing that built right into Git: git-worktree.

Git worktrees allow you to work on multiple branches simultaneously from a single repository copy - without having to stash or commit changes when switching between them.

Under the hood, Git shares objects across worktrees and only duplicates what’s actually been modified, rather than copying the entire .git/ directory.

Setup

Worktrees can be created anywhere, so I've opted to keep them local to each repo.

# From project root, create the directory
mkdir .worktrees

# Add to .gitignore
echo ".worktrees/" >> .gitignore

Creating a worktree + branch

Let’s say you’re starting from your repo’s base directory,~/projects/project , and already working on branch feature-a .

This following command will:

• Create a new worktree, .worktrees/fix-b
• Create a new branch, fix-b , based on main
• You remain on your current branch (feature-a)

# Create worktrees and branch on main
git worktree add .worktrees/fix-b -b fix-b main

Switching between worktrees

To switch to a worktree-backed branch, you actually just change directories (i.e. with cd) instead of using git checkout .

For instance…

# Switch to working on fix-b
cd .worktrees/fix-b
code . 
# or: open your editor/IDE of choice 
# Edit, commit, etc...

# Back to feature-a
cd ..
# or: cd ~/projects/project

Merging, rebasing, and cleaning up worktrees

# Go to project's main worktree
cd ~/projects/project
git checkout main
git merge fix-b
git push

# Clean up the fix-b worktree and branch
git worktree remove .worktrees/fix-b
git branch -d fix-b

# Rebase feature branch onto the updated main
git checkout feature-a
# or: cd ~/projects/feature-a   # if feature-a is in a worktree
git rebase main

Conclusion

Git worktrees were released back in 2015. Discovering them in 2026 gave me the conflicting feelings of “awesome, I’ve found a new-to-me tool to improve my workflows” and “how did I miss this for 10+ years?”

But as the saying goes: if the best time to learn something was yesterday, the second best time is today.

Worktrees are useful even without any agentic setup. If you’re in the middle of something and need to switch contexts, you can spin up a new worktree instead of doing git stash -u or a throwaway WIP commit.

The main downside is ergonomic: you have to remember to point your editors, dev servers, etc at the correct working directory. With branches alone, that’s a non-issue. So for many workflows, this is overkill.

Where worktrees are really useful is when you want true concurrency without duplicating repositories. That’s most often been the case for me when I’m working on task A while an AI agent works on task B—or, increasingly, when one agent works on task B while another works on task C.

In practice, worktrees have reduced friction around context switching and make it easier to work on independent tasks in parallel without extra tooling or process overhead.

In a follow-up post, I’ll share how this same mechanism becomes even more powerful when baked into agent skills, enabling automated, multi-agent planning, implementation, and review without turning a repository or file system into a mess.