Run Multiple Git Branches Simultaneously with git worktree

Git worktree lets you check out multiple branches into separate working directories without cloning the repository again or stashing changes. This native Git feature is a productivity hack that keeps context switching fast and your history clean.

What Is git worktree and Why Use It?

A git worktree creates an additional working tree linked to the same .git directory, sharing objects and refs while maintaining independent checked‑out files. Unlike a full clone, each worktree reuses the object database, so disk usage stays minimal and operations like fetch affect all worktrees instantly.

Developers typically reach for worktrees when they need to run tests on a feature branch while continuing work on main, or when a hotfix must be applied without disturbing an in‑progress rebase. The result is zero stashing, no duplicate clones, and a single source of truth for commits.

Setting Up a git worktree for Parallel Development

Follow these steps to add a new worktree for any branch, tag, or commit.

1. Navigate to your repository root – the directory that contains .git.
2. Run the add command – git worktree add ../feature-auth feature/auth creates a sibling folder ../feature-auth with the feature/auth branch checked out.
3. Verify the worktree list – git worktree list shows all linked worktrees, their paths, and the current HEAD.
4. Start working – open the new folder in your editor or terminal; commits made here appear in the shared history immediately.

Creating a Worktree for a New Branch

If the branch does not exist yet, add the -b flag: git worktree add -b hotfix/bug-123 ../hotfix-bug-123 origin/main. This creates the branch and the worktree in one command.

Removing a Worktree Safely

When the task is done, run git worktree remove ../feature-auth. Git will refuse removal if there are uncommitted changes, protecting you from accidental data loss.

Common git worktree Commands You’ll Use Daily

• git worktree add <path> [<branch>] – create a new linked working tree.
• git worktree list – display all worktrees with their locked status.
• git worktree lock <path> – prevent a worktree from being pruned or moved.
• git worktree unlock <path> – release a lock.
• git worktree prune – clean up stale administrative files after manual folder deletion.

Comparing git worktree to Alternative Approaches

Understanding trade‑offs helps you decide when a worktree is the right tool.

• Full clone – duplicates the entire object database; heavy on disk and network, but completely isolated.
• Stash & checkout – works for quick switches but clutters the stash list and risks merge conflicts on pop.
• Multiple IDE windows on same repo – shares the working tree, so file changes leak between tasks; not true parallelism.
• git worktree – shares objects, keeps separate checked‑out files, negligible overhead, and integrates with existing CI scripts.

Best Practices and Pitfalls to Avoid

• Keep worktree paths short and descriptive; long paths can hit filesystem limits on Windows.
• Lock long‑lived worktrees (e.g., a release branch) with git worktree lock to avoid accidental pruning.
• Do not manually delete a worktree folder; always use git worktree remove so Git updates its internal bookkeeping.
• Remember that HEAD in each worktree is independent – rebasing in one does not affect others.
• Use git worktree list --porcelain in scripts for reliable parsing.

Conclusion

Git worktree eliminates the friction of context switching by letting you run multiple branches side‑by‑side without stashing or recloning. Adopt it for hotfixes, parallel feature work, or any scenario where you need a clean, isolated workspace that still shares history. Actionable tip: add a shell alias gwt for git worktree and start a new worktree in a single keystroke.