Git Worktree.

Normally a Git repository has exactly one working folder. If you are working on one branch and urgently need to fix a bug on another, you have to stash your changes, switch branch, switch back later and hope nothing gets lost. Worktrees, a fixed part of Git since 2015, solve this: a command such as git worktree add ../shop-fix -b fix/cart creates a second folder with the new branch checked out. Both folders share the same history, but each has its own files.

The advantage over a second copy of the repository is that a worktree is lighter and stays connected. Commits made in one folder are immediately visible in the other; there is only one shared repository and no syncing between copies. Git also prevents the same branch from being checked out in two worktrees at once, which rules out many mix-ups. git worktree list shows all working folders, and git worktree remove cleans one up.

Since coding agents arrived, worktrees have seen a renaissance. Let two agents work in the same folder and they overwrite each other's files, and tests run on a mix of both changes. Give each agent its own worktree and it works in isolation on its branch. At the end the results are merged as usual. Tools are appearing on GitHub that automate creating, starting and cleaning up worktrees for agents.

It is not entirely without drawbacks. Depending on the project, each worktree needs its own installed dependencies, its own environment variables and sometimes its own port for the development server. Shared resources such as a local database are shared by all worktrees, which can cause conflicts. And parallel work only shifts the problem: if two agents change the same file in different places, merging produces a conflict. Clearly dividing tasks by file therefore remains important, see multi-agent system.