Git Worktree vs Branch: The Difference, With Commands

A branch changes which commit your one working copy points at. A worktree gives you a second working copy on disk, on its own branch, sharing one history. A clone gives you a separate repository with its own copy of the history. Three different things, often confused, because all three let you “work on two things at once”.

Here they are side by side:

	Working copies	History (`.git` objects)	Disk cost	Switching cost
Branch (`git switch`)	One, reused	One	None	Rebuild, reinstall, lose warm state
Worktree (`git worktree add`)	One per worktree	One, shared	Checked-out files only	`cd`
Clone (`git clone`)	One per clone	A separate copy each	Full repo each time	`cd`, plus fetch to sync

What a branch actually is

A branch is a movable pointer to a commit. It is roughly 40 bytes in .git/refs/heads/. Creating one costs nothing:

git switch -c feature/auth

What costs something is checking it out. Git rewrites your working directory to match the new commit. Your files change underneath whatever is holding them open: your editor, your dev server, your test watcher, your language server’s index, your agent session. Anything uncommitted has to be committed or stashed first.

That’s the real distinction. A branch is cheap. Switching branches is not, because there is only one set of files and every branch takes a turn using it.

Use a plain branch when you are working on one thing at a time and switching means genuinely putting the first thing down.

What a worktree adds

git worktree add gives the repository a second working directory, checked out to its own branch, with its own HEAD and its own index:

git worktree add ../myrepo-auth -b feature/auth

You now have two folders. Both are the same repository. A commit made in one is immediately visible in the other, because they share the object store. There is no fetching, no pushing, no remote in between.

Two rules follow from that sharing, and both trip people up:

The same branch cannot be checked out in two worktrees at once. Git refuses, with fatal: 'feature/auth' is already checked out at '/path/to/worktree'. This is the safeguard that stops two working copies from moving one branch pointer in opposite directions. It is also why git won’t let you delete a branch used by a worktree.
Untracked and ignored files do not come along. A new worktree contains tracked files only. No node_modules, no .env, no build output, no virtualenv. You install and copy those yourself, once per worktree.

Use a worktree when you need two things live at the same time: a long-running build on one branch while you edit another, a hotfix off main without disturbing a half-finished feature, or two agents editing the same project without overwriting each other.

What a clone adds

git clone https://github.com/you/myrepo.git myrepo-2

A clone is a separate repository. Its own objects, its own refs, its own config, its own hooks. The two copies only know about each other through a remote, so moving a commit between them means push and fetch.

That separation is the point when you actually want it. Testing a destructive history rewrite, running a fork, working against a different remote, or handing a copy to a machine that should not have your credentials. It is overkill when all you wanted was a second folder.

git worktree vs multiple clones

For parallel work on one project, worktrees beat clones on every axis that matters:

Disk. A worktree stores the checked-out files. A clone stores the checked-out files plus another full copy of the history. On a repo with years of commits and binary assets, that difference is measured in gigabytes.
Sync. Commits are instantly shared between worktrees. Between clones you push and fetch, which means a round trip and a chance to get out of date.
Branch safety. Git enforces one-checkout-per-branch across worktrees. Clones have no such protection, so two clones can happily diverge on the same branch name and hand you a merge later.
Cleanup. git worktree remove and git worktree prune are a known cleanup path. A stray clone is just a folder nobody remembers.

Clones win when you want the histories to actually be independent. That is a narrow case.

Picking one

One task at a time, sequential. Branch.
Two tasks live at once on the same project. Worktree.
A genuinely separate copy of the project. Clone.

The parallel-agent case sits squarely in the middle row. Agents like Claude Code or Codex work fast and autonomously, and two of them pointed at one working directory will overwrite each other’s edits inside a minute. Branches don’t help, because both sessions still share the same files. A worktree per agent is the fix, and it’s why claude --worktree exists as a built-in flag.

If you run this loop often, crystl creates the worktree, the branch, and the session in one step, then merges and cleans up when the work lands. See isolated sessions.

Git Worktree vs Branch (vs Multiple Clones)