Git Worktrees for Concurrent AI Coding: Keep Changes Separate

Git worktrees let multiple working directories use one repository while keeping separate checked-out branches and worktree-specific state. They are useful when a developer and coding assistants work on different tasks at the same time. They do not make concurrent edits automatically compatible, and they are not a security sandbox.

The goal is simple: each task gets an identifiable branch, a separate directory, and a clear integration owner. Without those boundaries, one assistant can overwrite another's files, tests can run against a changing checkout, and an innocent cleanup can remove unfinished work.

Understand what is separate and what is shared

The Git worktree documentation describes linked worktrees with their own working tree and index while sharing repository data. That distinction matters operationally. Separate directories reduce accidental file interference, but repository-level operations can still affect shared objects and references.

A worktree does not isolate credentials, network access, environment variables, shared databases, or installed services. Two tasks pointed at the same test database can still collide. If a task handles untrusted code, choose appropriate process and network controls separately; a branch name is not an access boundary.

Keep dependency caches separate when their tooling requires it, or use documented concurrency-safe caches. Never assume a build output directory is safe to share merely because the source files are separated.

Start each task from an explicit baseline

Check the current state before adding a directory:

git status --short
git worktree list
git rev-parse HEAD

These are inspection commands. They help identify existing user changes, current worktrees, and the baseline commit. Do not reset a dirty checkout just to obtain a cleaner starting point.

From a reviewed baseline, create a named task branch and directory:

git worktree add -b task/invoice-export ../invoice-export HEAD
git worktree add -b task/search-filter ../search-filter HEAD

Use paths that do not collide with existing directories. Git normally prevents checking out the same branch in multiple worktrees. Treat that guard as useful protection rather than forcing duplicate checkouts without a specific reason.

Record the baseline commit in the task brief. If another task changes the shared main branch later, the original task still has a stable reference for its review.

Assign ownership beyond files

Give each task a narrow outcome and identify likely overlap. For example, one task owns invoice serialization while another owns search filtering. If both need to change a shared API type, appoint one owner for that interface or schedule an integration step before the second task proceeds.

The task brief should include branch, directory, tests, files expected to change, prohibited external actions, and a stop condition for unexpected overlap. Assistants should not push, merge, deploy, or delete another task's work merely because repository permissions allow it.

Shared resources need explicit names. Use separate test database identifiers, temporary directories, and fixture accounts where appropriate. Avoid repurposing common system environment variables to point to task scratch space.

Review the change as a complete unit

Inspect the diff and tests from the task's own directory. Check for unrelated formatting, lockfile churn, generated artifacts, secrets, and hidden assumptions about the baseline. A passing unit test is not evidence that integration with another branch will work.

Compare the branch against the intended integration target, then choose the team's normal merge or rebase policy. Do not mix strategies casually when others already depend on branch history. If resolving a conflict, explain the semantic decision: a file that merges without markers can still combine two incompatible behaviors.

For a shared schema, run producer and consumer tests after integration. For a UI change, test the actual interaction rather than only compiling. For an automated coding task, verify that the implementation satisfies the original request rather than merely its own generated tests.

Handle interruption and cleanup carefully

When a task stops midway, leave a status note with branch, directory, last commit, uncommitted files, and failed tests. Preserve work that belongs to the user. A directory marked temporary may still contain valuable uncommitted edits.

Inspect status before removal and use Git's normal worktree removal process only after the work is safely committed, intentionally discarded with authorization, or otherwise preserved. Do not use broad recursive deletion or force options to suppress a warning about uncommitted files.

Pruning stale administrative entries is different from deleting an active task directory. Understand which operation you need before applying it. An offline or moved worktree may require investigation rather than immediate cleanup.

When worktrees are the right choice

Use them for bounded concurrent tasks, comparison testing, and reviewing a branch without disturbing the current checkout. Prefer sequential work when the tasks heavily modify the same architecture or when test infrastructure cannot support isolation.

Worktrees solve checkout interference, not coordination. The combination of explicit baselines, task ownership, separate resources, and reviewed integration is what makes concurrent AI coding dependable.