Git worktree

Git added worktrees in version 2.5. git worktree add ../feature-x feature-x creates a folder next to your repository with the branch feature-x checked out. Commits made there land in the same repository, so other worktrees see them at once, and nothing is downloaded twice: the objects live in the main .git folder. git worktree list shows every checkout, git worktree remove deletes one, and git worktree prune cleans up records of folders that were deleted by hand. One rule keeps them safe: a branch can be checked out in only one worktree at a time.

Worktrees exist for parallel work. Without them, switching to a hotfix means stashing half-finished changes, changing branches, rebuilding, and switching back. With them, the hotfix gets its own folder and your feature work stays exactly as you left it. They are also cheaper than a second clone, because the history is shared and a new worktree costs only the files of one checkout.

AI coding agents made worktrees popular again. One agent in one checkout is fine. Two agents in the same checkout edit the same files, overwrite each other, and break each other's builds halfway through. Giving each agent its own worktree and branch isolates their edits the way separate developers are isolated, and the results come back together through ordinary merges or pull requests.

They are not free. Each worktree has its own untracked files, so dependencies such as node_modules, build caches and local environment files have to be installed or copied again. Two worktrees can still fight over the same port, database or external service. Changes in one worktree are invisible to the others until they are committed and merged, so conflicts move from the working folder to the merge step instead of disappearing.