Shipping from many hands (and AI agents) into one repo without collisions

We routinely have more than one worker shipping into the same repository at the same time — sometimes two people, increasingly two or more AI coding agents running in parallel, each building a different feature against the same main branch. That is a recipe for collisions: two workers editing near each other, half-finished work landing on main, force-pushes clobbering commits. Here is the workflow that keeps it clean.

The problem with everyone sharing one working copy

The naive setup is one checkout of the repo, and whoever is working switches branches in it. The moment two workers share that single working directory you get chaos: switching branches stomps on uncommitted work, one agent's edit lands in another's commit, and "who changed this file" becomes unanswerable.

The fix is isolation at the filesystem level, not just the branch level.

Git worktrees: one repo, many isolated working copies

Git worktrees let a single repository have multiple working directories checked out at once, each on its own branch, sharing one object store. Each worker — human or agent — gets a worktree created off the latest origin/main. They edit, build, and commit entirely inside their own directory. Nobody is switching branches under anybody else. Nobody's uncommitted work is at risk from someone else's checkout.

Created fresh off origin/main, a worktree is a clean room: the worker sees exactly main plus their own changes, nothing else in flight.

Fast-forward-only integration

The second half of the discipline is how work gets back to main. We push each worktree's branch to main as a fast-forward only. If main has moved since the worktree was created, the push is rejected, and the worker rebases onto the new main and tries again. No merge commits papering over divergence, no force-pushes overwriting someone else's work. Main only ever moves forward, one clean commit chain.

This matters most with parallel agents. An agent that blindly merges or force-pushes can silently erase a commit another agent just landed. Fast-forward-only makes that impossible: the push simply fails, and the agent has to reconcile with reality first.

Commit by name, never "add everything"

The third rule: commit specific files by name, never a blanket "stage everything." When multiple workers share a repo's history — and especially when an environment has unrelated uncommitted changes lying around (a half-done config, a generated file, another worker's experiment) — staging everything sweeps up things that should not be in your commit. Naming the files you actually changed keeps each commit tight and attributable, and keeps you from accidentally shipping someone else's work-in-progress.

Why this works for AI agents specifically

The same properties that help a human team are the ones that make parallel AI agents safe:

An agent does not get tired, but it also does not have a human's instinct for "wait, that file is not mine." The workflow has to enforce what instinct would. Worktrees plus fast-forward-only plus commit-by-name encode that instinct as rules the tooling enforces.

The one cost

Worktrees are not free: each is a full working directory on disk, and for some toolchains each needs its own dependency install. For a heavy dependency tree that is real disk and setup time. We treat worktrees as disposable — create off main, do the work, push, remove. The cleanup matters; orphaned worktrees pile up fast when you create one per feature.

What I would tell another team

We run this every day with a mix of human and agent contributors against shared main branches. It is the difference between parallelism that compounds and parallelism that corrupts.

If you are figuring out how to let AI agents ship real code into a real repo without stepping on each other, [we have opinions](https://bluewaveprojects.com/booking).

More from BlueWave