Worktrees

Birch Code is built around Git worktrees as the primary unit of work. Instead of one working copy that you flip between branches with git checkout, you keep one working copy per task — and switch tasks by switching folders.

Why worktrees

In a traditional flow, every branch share a single working directory. To start a new task you have to:

• Stash or commit uncommitted changes,
• git checkout the new branch,
• Wait for IDE re-indexing, build cache invalidation, file watchers to settle.

The cost is real: even a quick context-switch can take a minute, and git stash is famously easy to lose work in.

A worktree gives each task its own checkout — its own files on disk, its own staged changes, its own dev server. Switching tasks is just cd (or in Birch Code: a click).

The Birch Code flow

When you open a repository in Birch Code, it creates a parent directory that holds one folder per worktree. A typical layout:

my-project/
├── main/                 ← the default branch
├── feature-auth/         ← worktree for the auth feature
├── bugfix-login/         ← worktree for a bugfix
└── .bare/                ← shared .git data

Each worktree has the full repo state from its branch. They all share the same .git storage under the hood, so disk usage stays low.

What this means in practice

• No stashing. Your uncommitted edits stay where you put them — in the worktree they belong to.
• No re-indexing. Switching tasks doesn’t touch the worktree you’re not on. IDEs stay warm.
• Parallel reviews. Reviewing a PR can happen in a fresh worktree while your feature work continues untouched.
• Easier rebasing. You can interactively rebase a feature worktree while running tests in another.

Next steps

• Migrate an existing repo into the worktree layout
• Birch Code CLI: spin up worktrees from ticket numbers