Multitasking with Cursor: Using Git Worktree for Parallel Branch Development

Context switching between branches is one of the most underrated sources of lost time in engineering. You're deep in a feature, a hotfix comes in, you stash your work, checkout main, fix the bug, push, checkout your feature branch, pop your stash, rebuild your mental model of where you were. Twenty minutes gone.

Git worktrees eliminate this. They let you have multiple branches checked out simultaneously in separate directories. Combined with Cursor's AI assistance, they unlock genuine parallel development without the overhead.

What git worktree actually does

A git worktree is a linked working tree — a separate directory that references the same repository, with its own branch and working state. Unlike git clone, worktrees share the same .git object store, so they're cheap to create and don't duplicate the repository.

The basic commands:

# Add a new worktree on an existing branch
git worktree add ../my-repo-feature feature/my-feature

# Add a new worktree on a new branch
git worktree add -b feature/new-thing ../my-repo-new

# List all worktrees
git worktree list

# Remove a worktree when done
git worktree remove ../my-repo-feature

The Cursor workflow

Cursor opens a project by directory. Open each worktree as a separate Cursor window. Now you have two fully independent AI-assisted development environments pointing at different branches of the same repository.

The practical flow we use:

• Main feature work happens in the primary worktree
• Hotfixes get their own worktree — fix, test, push, close the window
• Code reviews happen in a third worktree — you can run the branch locally while still working on something else
• Long-running AI generation tasks in Cursor run in the background while you work in another worktree

What changes with AI assistance

Before Cursor, parallel development with worktrees was useful but had a natural limit — one developer can only actively think about one thing at a time. With Cursor, you can kick off a longer AI-assisted task (refactoring a module, generating tests, writing a migration) in one window and switch to another worktree while it runs.

The mental model shift: Cursor changes your ratio of active thinking to passive review. You set direction, review output, steer. With worktrees, "set direction and let it run" becomes truly parallel.

Gotchas

A few things to watch:

• One branch per worktree — you can't check out the same branch in two worktrees simultaneously. This is a feature, not a bug; it prevents the confusion of editing the same branch in two places.
• Shared dependencies — if both worktrees need npm install or bundle install, they're independent. Changes to package.json in one worktree don't affect the other until you run install in each.
• Running services — if both worktrees try to start a dev server on port 3000, one will fail. Use different ports.
• Stale worktrees — worktrees that aren't cleaned up accumulate. git worktree prune removes references to deleted directories.

When to use it

Worktrees are highest-value when:

• You regularly context-switch between a feature and hotfixes
• You review PRs locally (open the branch in a separate worktree, run it, review it)
• You're using AI assistance for longer generation tasks and want to stay productive while they run
• You're working on a long-lived feature branch and need to keep a stable main available

For smaller teams or solo developers, worktrees often feel like overkill. Once you've been burned by stashing-and-losing-your-place once too many times, they become a habit you don't give up.