A Practical Git Worktree Workflow for Parallel Development

A Practical Git Worktree Workflow for Parallel Development

Git worktrees let you work on multiple branches at once without stashing, switching back and forth, or cloning the repository again. This guide shows how to use them to keep feature work, bug fixes, and code reviews isolated while staying fast and organized.

Why worktrees help

A worktree is a separate working directory linked to the same Git repository, so it has its own files and branch checkout while sharing the same object store. That means you can keep your main branch clean and spin up a second, third, or fourth task area almost instantly.

This is especially useful when you need to juggle multiple tasks, debug a problem without interrupting your current branch, or review a pull request while keeping your active work untouched.

Core idea

Instead of one repo directory trying to hold every task, each task gets its own directory and branch. Git still stores the history in one place, but your working copies are separated, which reduces accidental context switching and makes branch ownership clearer.

A simple mental model is: one repository, many working folders, one branch per folder. Git also requires each worktree to be on a unique branch, which prevents two directories from writing to the same branch at the same time.

Set up a worktree

Start from your main repository and create a dedicated worktree for a task branch. A common pattern is to place the new worktree beside the main repo directory.

### from your main repository
git status
git switch main
git pull

### create a new branch and worktree in one step
git worktree add ../project-feature-x -b feature/x

### move into the new worktree
cd ../project-feature-x

Now you can edit files, run tests, and commit changes in feature/x without touching your original checkout. The main directory stays available for other work, releases, or clean inspection.

A daily workflow

A good worktree routine is simple: create a branch for each task, work in that directory only, then clean it up when the task is done. That keeps your mental model small and your repository history easier to follow.

1. Create a worktree for the task.
2. Make small, focused commits in that worktree.
3. Open a pull request from that branch.
4. Merge it when approved and tested.
5. Remove the worktree after the branch is no longer needed.

Example session:

git worktree add ../project-bugfix-214 -b bugfix/214
cd ../project-bugfix-214

### make changes
git add .
git commit -m "fix: handle empty response"

git push -u origin bugfix/214

Handling multiple tasks

Worktrees shine when you have several independent jobs in flight. For example, you can keep a feature branch in one directory, a bug fix in another, and a refactor in a third. This avoids the common habit of stashing work just to jump between unrelated tasks.

git worktree add ../repo-feature-a -b feature/a
git worktree add ../repo-bugfix-b -b bugfix/b
git worktree add ../repo-refactor-c -b refactor/c

Each directory becomes a dedicated workspace. That makes it much easier to run focused tests, compare behavior, or isolate breaking changes without disturbing unrelated work.

Useful commands

A few commands cover most of the lifecycle. Git documents worktree management directly, and the typical operations are add, list, move between directories, and remove once you are done.

git worktree list
git worktree add ../docs-update -b docs/update-readme
git worktree remove ../docs-update
git worktree prune

git worktree list shows all attached working directories, which is helpful when you forget where a branch lives. git worktree prune cleans up stale entries after a directory is deleted or moved.

Good practices

Use worktrees for tasks that are independent enough to live on separate branches. They are a great fit for features, bug fixes, docs changes, and review branches, but they are not a substitute for good branch discipline.

Keep branch names descriptive and short, and try to finish or pause tasks cleanly before starting another worktree. Since every worktree has its own files, it is easier to avoid accidental overwrites, but you still need clear commit messages and regular pushes.

When not to use them

Worktrees are less helpful if you only ever handle one small change at a time. They also add a little setup overhead, so teams that rarely multitask may prefer a simpler branch-only routine.

They are also not the same as stashing. Stash is for temporarily parking uncommitted changes, while worktrees give you a fully separate live workspace. If you often stash just to switch tasks, worktrees are usually the cleaner option.

Example team flow

Here is a practical team setup for a small product team:

### main repo stays on main
cd ~/code/app
git switch main
git pull

### create a review workspace
git worktree add ../app-review-pr-184 -b review/pr-184

### create a feature workspace
git worktree add ../app-auth-refresh -b feature/auth-refresh

One engineer can keep the feature branch moving while another checks a pull request or investigates a bug in a separate worktree. That separation helps reduce merge confusion and keeps the main checkout free for release work or quick verification.

Cleanup routine

When a branch is merged or abandoned, remove its worktree and prune leftovers. This keeps your disk tidy and prevents outdated directories from lingering in your setup.

git worktree remove ../app-review-pr-184
git branch -d review/pr-184
git worktree prune

A clean exit matters because worktrees are meant to be disposable task spaces, not permanent second homes for old branches. Treat them like project-specific desks you clear off after the job is finished.

Final workflow

If you want a simple default, use this pattern: one branch, one worktree, one task. It keeps your changes isolated, makes multitasking easier, and reduces the need for stashing or repeated branch switching.

That workflow is especially strong for developers who review code, handle bug fixes, and build features in parallel. It gives you the speed of a shared repository with the focus of separate workspaces.

-

Rizwan Saleem | https://rizwansaleem.co