git worktree: Checking Out Multiple Branches Simultaneously
Every branch-switching operation covered so far — `git switch`, `git checkout` — assumes only one branch can be checked out at a time in your working directory. `git worktree` breaks that assumption, letting you have multiple branches checked out simultaneously, each in its own separate folder, all sharing the exact same underlying repository history.
Learning Objectives
- Explain the problem git worktree solves compared to constant branch switching.
- Create a new worktree for an existing or new branch.
- List and remove worktrees.
- Understand how worktrees relate to (and differ from) simply cloning the repository multiple times.
Key Terms to Know Before Using git worktree
- git worktree: A feature allowing multiple working directories, each with a different branch checked out, to exist simultaneously and share the same underlying repository.
- Linked worktree: An additional working directory created with git worktree add, distinct from the repository's original, primary working directory.
- git worktree add: The command that creates a new linked worktree for a specified (existing or new) branch.
- git worktree list: Displays all currently active worktrees associated with a repository.
How git worktree Actually Works
A common friction point in daily Git use: you're deep in the middle of uncommitted work on a feature branch, and suddenly need to quickly check something on `main`, or urgently create a hotfix branch (Module 3). The traditional options are imperfect — stashing your work (Module 3) and switching, which works but adds interruption overhead, or maintaining a completely separate `git clone` of the same repository in another folder, which works but duplicates the entire repository's storage and requires manually keeping both clones' remotes in sync.
`git worktree` offers a better solution: it lets you check out **multiple branches simultaneously**, each in its own separate folder (a 'linked worktree'), while all of them **share the exact same underlying repository** — the same `.git` object database, the same remotes, the same configuration — meaning no duplicated storage and no separate syncing required between them.
Creating a new worktree for an existing branch:
```
git worktree add ../hotfix-work hotfix/payment-crash
```
This creates a new folder (`../hotfix-work`, a sibling directory to your current repository folder) with the `hotfix/payment-crash` branch checked out there — completely independently of whatever branch remains checked out in your original working directory. You can now have two separate terminal windows or editor instances open, one in each folder, working on two entirely different branches simultaneously, with no need to stash, switch, or interrupt either one.
You can also create a **new** branch and its worktree in one step:
```
git worktree add -b feature/new-idea ../new-idea-work main
```
This creates a new branch `feature/new-idea` (based on `main`) and immediately checks it out in a new `../new-idea-work` folder.
To see all currently active worktrees for a repository:
```
git worktree list
```
And to remove a worktree once you're done with it (after committing or discarding any changes in it):
```
git worktree remove ../hotfix-work
```
A useful mental model for when worktree genuinely helps: it's ideal for situations requiring **genuinely parallel** work on two branches at once — running a test suite on one branch while actively developing on another, comparing behavior between two versions side by side, or handling an urgent interruption without disturbing carefully staged, in-progress work elsewhere. For simple, sequential context switches (finish this, then look at that), plain `git switch` remains simpler and perfectly adequate — worktree specifically shines when you need multiple branches' files present and usable *at the same time*.
git worktree: Visual Walkthrough
Draw a single '.git' database icon in the center, shared by three separate folder icons radiating outward: 'my-project/ (main branch checked out)', 'my-project-hotfix/ (hotfix/payment-crash checked out)', 'my-project-newidea/ (feature/new-idea checked out)'. Caption: 'All three folders share the SAME underlying repository history, remotes, and configuration — no duplicated storage, no manual syncing between them.' Contrast with a crossed-out alternative showing three completely SEPARATE '.git' clones, captioned 'The old way: full duplicated clones, requiring manual remote syncing.'
git worktree vs Multiple Clones: Key Differences
| Aspect | git worktree | Multiple git clone copies |
|---|---|---|
| Underlying storage | Shared — one .git database for all worktrees | Duplicated — a full separate copy per clone |
| Remote/config syncing needed? | No — all worktrees share the same remotes/config | Yes — each clone's remotes must be independently managed |
| Setup command | git worktree add <path> <branch> | git clone <url> <path> (repeated for each copy) |
| Best for | Genuinely parallel work on multiple branches at once | Working with an entirely separate, unrelated project |
git worktree: Command Syntax and Examples
# Create a new worktree for an EXISTING branch
git worktree add ../hotfix-work hotfix/payment-crash
cd ../hotfix-work
# hotfix/payment-crash is now checked out here, independently
# Create a NEW branch and its worktree in one step
git worktree add -b feature/new-idea ../new-idea-work main
# List all active worktrees
git worktree list
# /path/to/my-project a1b2c3d [main]
# /path/to/hotfix-work 9f8e7d6 [hotfix/payment-crash]
# /path/to/new-idea-work 3c4d5e6 [feature/new-idea]
# Remove a worktree once finished with it
git worktree remove ../hotfix-work
Breaking Down the git worktree Example
The first command creates a completely separate folder with `hotfix/payment-crash` checked out, ready to work in immediately without disturbing whatever branch remains checked out in the original repository folder. The second demonstrates creating a brand-new branch and its worktree together in a single step. `git worktree list` confirms all active worktrees and which branch each has checked out, and `git worktree remove` cleans one up once it's no longer needed — all while every one of these folders shares exactly the same underlying `.git` repository, remotes, and configuration.
How git worktree Is Used on Real Engineering Teams
- Developers handling an urgent hotfix (Module 3) while in the middle of substantial, carefully staged feature work commonly use a worktree to address the hotfix in a completely separate folder, without needing to stash or interrupt their existing work at all.
- Some developers maintain a dedicated, long-lived worktree specifically for running a project's full test suite on the latest main branch, while their primary worktree remains on whatever feature branch they're actively developing.
- Reviewing a colleague's pull request locally (Module 5) sometimes uses a dedicated worktree rather than switching the primary working directory, letting a developer compare the PR's behavior side-by-side with their own ongoing work.
- Teams working with build processes that take a long time (compiling a large codebase, for example) sometimes use worktrees to kick off a build on one branch while continuing active development on another, without waiting for the build to finish before switching.
git worktree Interview Questions and Answers
Q1. What problem does git worktree solve, and how is it different from maintaining multiple separate clones?
It lets you check out multiple branches simultaneously, each in its own folder, without the constant stash/switch interruption of sequential branch switching, and without the storage duplication and manual remote-syncing overhead of maintaining multiple separate clones. All worktrees share the exact same underlying repository, remotes, and configuration.
Q2. How would you create a new worktree for an existing branch?
Run git worktree add <path> <branch-name>, such as git worktree add ../hotfix-work hotfix/payment-crash, which creates a new folder with that branch checked out there, completely independent of whatever branch remains checked out in the original working directory.
Q3. In what kind of situation is git worktree the right tool, as opposed to simply using git switch?
Worktree shines when you need genuinely parallel access to multiple branches' files at the same time — such as handling an urgent interruption without disturbing in-progress staged work, running tests on one branch while developing on another, or comparing behavior between two branches side by side. For simple, sequential context switching, plain git switch remains simpler and sufficient.
git worktree Quiz: Test Your Understanding
1. What is the key advantage of git worktree over maintaining multiple separate clones of the same repository?
- Worktrees are faster to create than a clone, but otherwise identical
- All worktrees share the same underlying repository, remotes, and configuration, avoiding duplicated storage and manual syncing
- Worktrees only work with private repositories
- Worktrees automatically merge all branches together
Answer: B. All worktrees share the same underlying repository, remotes, and configuration, avoiding duplicated storage and manual syncing
Explanation: Unlike separate clones, which each require their own full storage and independently managed remotes, worktrees all share one underlying repository, eliminating both duplication and synchronization overhead.
2. What does git worktree add ../hotfix-work hotfix/payment-crash do?
- Deletes the hotfix/payment-crash branch
- Creates a new folder with hotfix/payment-crash checked out there, independent of the original working directory
- Merges hotfix/payment-crash into the current branch
- Renames the current repository
Answer: B. Creates a new folder with hotfix/payment-crash checked out there, independent of the original working directory
Explanation: This command creates a new linked worktree — a separate folder with the specified branch checked out — while sharing the same underlying repository as the original working directory.
3. In which scenario is git worktree most clearly the right tool, compared to simple git switch?
- Making a single small text edit to one file
- Needing genuinely simultaneous, parallel access to two different branches' files at once
- Viewing a repository's commit history
- Deleting an old, unused branch
Answer: B. Needing genuinely simultaneous, parallel access to two different branches' files at once
Explanation: Worktree specifically addresses the need for multiple branches' files to be present and usable at the same time, unlike sequential switching, which is better suited to simple, one-at-a-time context changes.
Common git worktree Mistakes Beginners Make
- Maintaining separate full clones for parallel branch work, unaware that worktree accomplishes the same goal without duplicating storage or requiring separate remote management.
- Using worktree for simple, sequential context switches where plain git switch would have been simpler and perfectly adequate.
- Forgetting to remove a worktree once it's no longer needed, leaving stale, unused folders cluttering the file system.
- Attempting to check out the same branch in two different worktrees simultaneously, which Git prevents, since a branch can only be checked out in one worktree at a time.
git worktree: Exam-Ready Quick Notes
- git worktree add <path> <branch>: creates a new linked worktree, checking out that branch in a separate folder.
- All worktrees share the same underlying .git repository, remotes, and configuration — no duplicated storage.
- git worktree list: shows all active worktrees. git worktree remove <path>: removes one.
- A given branch can only be checked out in ONE worktree at a time.
git worktree: Key Takeaways
- git worktree solves the genuine friction of needing multiple branches' files available simultaneously, without duplicating storage or requiring separate clones.
- All worktrees for a repository share the exact same underlying history, remotes, and configuration, eliminating manual syncing between them.
- Worktree is most valuable for genuinely parallel work; simple sequential context switches remain better served by plain git switch.
Frequently Asked Questions About git worktree
Q1. What does git worktree do?
It lets you check out multiple different branches at the same time, each in its own separate folder, while all of them share the exact same underlying repository history, remotes, and configuration — no need to duplicate the entire repository or constantly switch branches back and forth.
Q2. How do I create a new worktree for an existing branch?
Run git worktree add <folder-path> <branch-name>, for example git worktree add ../hotfix-work hotfix/payment-crash, which creates a new folder with that branch checked out there, independent of your original working directory.
Q3. How is git worktree different from just cloning the repository again in a new folder?
A separate clone duplicates the entire repository's storage and requires you to manage its remotes independently. A worktree shares the exact same underlying repository as your original folder, avoiding duplication and keeping everything automatically in sync.
Q4. When should I use git worktree instead of just switching branches normally?
Worktree is most useful when you genuinely need multiple branches' files available and usable at the same time — like handling an urgent interruption without disturbing in-progress staged work, or running tests on one branch while developing on another. For simple, one-at-a-time context switches, plain git switch remains simpler.
Q5. How do I remove a worktree once I'm done with it?
Run git worktree remove <folder-path>, after making sure any changes in that worktree have been committed or intentionally discarded, to clean it up and stop it from being tracked as an active worktree.
Summary
`git worktree` lets you check out multiple branches simultaneously, each in its own separate folder, while all worktrees share the exact same underlying repository — its history, remotes, and configuration — avoiding both the interruption of constant stash-and-switch cycles and the storage duplication and manual syncing overhead of maintaining multiple separate clones. `git worktree add <path> <branch>` creates a new linked worktree for an existing or newly created branch, `git worktree list` shows all active worktrees, and `git worktree remove <path>` cleans one up once no longer needed. Worktree is most valuable for genuinely parallel needs — handling an urgent interruption without disturbing carefully staged work, running tests on one branch while developing on another, or comparing two branches side by side — while simple, sequential context switching remains better served by plain `git switch`.