skip to content

What does git worktree add create, and how does it differ from a second git clone?

level: juniorimportance: must knowfreq 45%

answer

  1. Several checkouts, one repository
  2. No second fetch, no duplicated history
  3. Refs and objects are shared
  4. The linked root has a .git file, not a directory
  5. git worktree list shows them all

basics

~20 s

It creates an additional working directory with its own checked-out branch, backed by the same repository. Unlike a second clone it shares one object database and one set of branches, so it costs no extra fetch and no duplicated history.

solid answer

~50 s

`git worktree add ../review origin/main` (or `-b hotfix ../hotfix`) makes a new directory containing a checkout of that commit or branch, linked to your existing repository. The linked directory has a `.git` **file**, not a directory, pointing back into the original repository's administrative area. Because there is one object database and one set of refs, a `git fetch` in any worktree updates all of them, commits made in one are immediately visible in the others, and you use only the disk needed for the extra checkout rather than a second copy of the whole history. A second `git clone` gives you an independent repository: separate objects, separate branches, separate remotes, and you must push and fetch between the two to move work across. `git worktree list` shows every worktree and the branch each has checked out.

code

bash · 5 lines
bash
git worktree add ../review feature-x
git worktree add -b hotfix ../hotfix main
git worktree add --detach ../inspect v2.1.0

git worktree list

go deeper

for a junior

Recall the command and its point: an extra checkout directory on another branch, sharing one repository, so you can work on two branches without a second clone.

for a middle

Explain what is shared — objects, refs, remotes — versus what is per-directory, and describe the .git file that points into the original repository's worktrees area.

for a senior

Bring in the operational reality: ignored files and build outputs are per-worktree, so provisioning cost is real, and concurrent builds from two worktrees can collide on shared output paths.

for a principal

Own the workflow decision — whether standardising on worktrees beats extra clones for your team's repository size, CI checkout style, and tooling, and what conventions (naming, location, teardown) keep them from accumulating.

## The problem You are halfway through a change and something else needs a different branch checked out — a build to run against `main`, a colleague's branch to look at, a long compile you do not want to interrupt. Switching branches disturbs your working tree. Cloning again works but is wasteful and awkward. `git worktree` is the built-in answer: **several working directories attached to one repository**. ## What add does `git worktree add <path> [<commit-ish>]` creates the directory at `<path>` and checks out `<commit-ish>` there. Common forms: - `git worktree add ../review feature-x` — check out an existing branch in a new directory. - `git worktree add -b hotfix ../hotfix main` — create branch `hotfix` from `main` and check it out there. - `git worktree add --detach ../inspect v2.1.0` — check out a tag or commit with a detached HEAD, useful for a build or a look-around where you do not want a branch. - `git worktree add ../thing` with no commit-ish — recent Git creates a new branch named after the path's last component, based on HEAD. The first, original checkout is the **main worktree**; the ones you add are **linked worktrees**. ## What makes it different from a clone A clone creates a second, independent repository: its own `.git` directory, its own copy of every object, its own branches and remotes. Work moves between the two only over the transport — push and fetch — and a `git fetch` in one does nothing for the other. Disk usage roughly doubles, and on a large repository the initial clone is slow. A linked worktree shares the original repository's storage. That gives you: - **One object database.** No re-download, no second copy of history. Adding a worktree costs a checkout, not a clone. - **One set of refs.** Branches and tags are the same set everywhere. A commit made in one worktree is instantly available in the others by SHA or branch name; `git log` in the main worktree sees it with no fetch. - **One remote configuration.** `git fetch` in any worktree updates the remote-tracking branches all of them read. - **A quick teardown.** `git worktree remove <path>` deletes the checkout and its bookkeeping; the objects stay where they are. Because the storage is shared, the branch you check out in a linked worktree is the *same* branch object the main worktree can see — which is why Git enforces that a given branch is checked out in at most one worktree at a time. ## What appears on disk At the linked worktree's root there is a **`.git` file** rather than a directory. It contains a single line of the form `gitdir: /path/to/repo/.git/worktrees/<name>`. That per-worktree administrative directory inside the original repository holds this checkout's own `HEAD`, its own index, and its own reflog for HEAD. Everything heavy — `objects/`, `refs/`, the config — stays in the original repository and is shared. The mechanism is why moving a linked worktree by hand breaks it (the two pointers no longer agree) and why `git worktree move` exists. ## Typical uses - Reviewing or testing someone else's branch while your own change stays untouched in another directory. - Running a long build or test suite on one branch while you keep coding on another. - Bisecting or debugging an old release in a dedicated directory. - Comparing behaviour of two branches side by side with two editors or two servers running. ## What you still have to think about Each worktree has its own working directory, so untracked and ignored files — build outputs, dependency directories, local environment files — are **not** shared. A new worktree usually needs its own dependency install and its own build, which is often the real cost rather than the checkout itself. And two worktrees of the same repository can compile concurrently, so if your build writes to a path derived from the repository rather than the checkout, they can collide. ## Managing them `git worktree list` prints every worktree with its path, the commit checked out and the branch (or `detached`). `git worktree remove <path>` tears one down cleanly. `git worktree move <old> <new>` relocates one and fixes both pointers. `git worktree prune` clears bookkeeping for worktrees whose directories no longer exist.

  • If you commit in a linked worktree, does the main worktree need to fetch to see it?
    No. The object database and refs are shared, so the commit and any branch update are visible immediately from every worktree — `git log` and `git show` in the main checkout find it without any transfer. This is the practical difference from a second clone, where the same work would have to be pushed and fetched.
  • Are build outputs and ignored files shared between worktrees?
    No. Each worktree has its own working directory, so untracked and ignored files — compiled output, dependency directories, local environment files — exist separately in each. A fresh worktree typically needs its own dependency install and build, which is often the dominant cost of adding one.
  • How do you create a worktree that is not on any branch?
    Use `git worktree add --detach <path> <commit-ish>`, for example a tag or a commit SHA. HEAD in that worktree is detached, which is what you want for building or inspecting an old release without occupying a branch name — and it sidesteps the rule that a branch may be checked out in only one worktree.

saying these in an interview costs you the question

  • Says each worktree has its own copy of the repository history
  • Thinks you must fetch to move commits between worktrees
  • Expects build artifacts to be shared across worktrees
  • Claims a linked worktree contains a full .git directory
  • Believes worktrees can be deleted safely with rm -rf alone

context

resolving links…