Git Worktrees vs Clones
Worktrees share one repository. Clones create separate repositories.
Introduction
Git worktrees and clones both give you another directory in which to check out files. A worktree links that directory to an existing repository. A clone builds a whole new repository with its own object database, refs, config, and admin state.
Pick between them on the isolation you need, not just on setup time or disk use.
Understanding the Concept
A linked worktree has its own working tree, HEAD, and index. It shares the object database and most refs with the main worktree. Git keeps its admin files under the common Git directory.
Definition
Linked Worktree
An additional working directory attached to an existing Git repository, with its own HEAD and index but a shared object database and shared refs.
A clone has its own Git directory. Its local branches, remote-tracking refs, config, reflogs, stash, and object database all move on their own, with no effect on another clone.
Definition
Clone
A separate Git repository created from another repository, with its own administrative state and object database.
| Linked worktree | Clone | |
|---|---|---|
| Object database | Shared | Separate by default |
| Local branches and tags | Shared | Separate |
HEAD and index | Per worktree | Per clone |
| Repository config | Mostly shared | Separate |
| Reflog and stash | Shared repository state | Separate |
| Commit visibility | Immediate | Requires fetch or another transfer |
| Same branch checked out twice | Blocked by default | Allowed |
| Cleanup | git worktree remove | Remove the clone directory |
Worktrees save you copying Git objects, but each checkout still holds a full set of working files unless sparse checkout or a filesystem trick cuts it down. Clones can share objects too, through local clone optimizations or alternates, so a clone is not always a full copy on disk. Sharing objects does not make their refs or config shared.
Applying It in Practice
Create a temporary worktree for a review:
git fetch origin
git worktree add --detach ../review-hotfix origin/hotfix/payment
A detached HEAD is enough when you only want to read or test the commit. Create a branch when you plan to make changes:
git worktree add -b fix/payment ../fix-payment origin/main
List and remove linked worktrees through Git:
git worktree list
git worktree remove ../fix-payment
Use a clone when the second checkout needs its own settings or its own lifecycle:
git clone git@github.com:org/repo.git ../repo-integration
git -C ../repo-integration remote set-url origin git@staging.example.com:org/repo.git
Credentials are not stored per clone. Git can pull them from a global credential helper, an SSH agent, the environment, or the OS keychain. Separate clones let you set different remotes and repo-level credential settings, but full credential isolation needs a separate process or account.
Engineering Considerations
Worktrees fit parallel work in one trusted repository. Commits and branches show up at once, setup is quick, and a single fetch updates remote-tracking refs for every worktree. They are a good default for local reviews and for coding agents that run under the same trust boundary.
Shared state is the catch. A fetch, a branch deletion, a tag update, a stash, or a maintenance command can hit every linked worktree. Hooks come from the common Git directory unless something like core.hooksPath says otherwise. Git can hold some config per worktree through extensions.worktreeConfig, but you have to turn that on yourself.
Clones fit jobs that need their own refs, config, maintenance, or deletion. They are not a security boundary on their own. Two clones running as the same OS user still reach the same files, credentials, processes, and network.
Scaling and Operations
Give every concurrent writer its own branch. By default Git blocks one local branch from being checked out in two linked worktrees, because both directories could race to move the same ref.
Do not delete linked worktree directories by hand. If a process dies before cleanup, prune the stale records:
git worktree prune
For large pools of short-lived jobs, measure Git object size and working-tree size separately. Worktrees cut duplicate object storage, but installed dependencies, build output, and generated files usually take up far more space.
Use clones or a stronger sandbox when jobs must not share Git refs or config. Choosing between them for agents walks through the decision. Use containers, virtual machines, or separate user accounts when they must not share credentials or host access.
Next Steps
- What are Git Worktrees?: learn the worktree lifecycle and shared-state model
- Parallel Development Workflow: use isolated directories for concurrent work
- What are Coding Agents?: understand why agents need separate working directories