Branch, worktree, and fork sit at three layers of Git: a branch is a movable commit pointer, a worktree is an additional working directory on one repository, and a fork is a server-side copy of an entire repository under another account.
A branch is a lightweight, movable pointer to a commit. Creating one copies nothing — it writes a small reference holding a commit hash that advances as new commits are made. A repository's branches all share one object database, but a working directory holds only one branch at a time, so switching rewrites the working tree to match the target.
A worktree is an additional working directory attached to the same repository through the git worktree command. It allows several branches to be checked out at once — each in its own folder with its own index — while sharing the underlying object store. This removes the need to stash in-progress work before switching contexts, and because history and objects are shared rather than re-cloned, it is inexpensive in both disk and time.
A fork is a server-side copy of an entire repository hosted under a different account — a feature of platforms such as 📝GitHub, GitLab, and Bitbucket rather than of Git itself. It is the standard way to contribute to a project without write access: fork the repository, clone the fork, push changes to it, and open a pull request back to the upstream. In Git terms a fork is nearly identical to a clone — both are complete, independent copies, differing only in where they live and who owns them. Branches and worktrees, by contrast, never leave the repository they belong to.
For our work the worktree is the load-bearing one. The entire parallel-agent setup depends on it — many agents, many working directories, one shared object store, zero stash collisions. Branch isolation is policy; worktree isolation is what mechanically keeps concurrent agents from clobbering one another.