Running Multiple Repositories in Parallel with Antigravity 2.0 Projects and Worktrees

Combining Antigravity 2.0 projects with git worktrees to run several repositories in parallel safely. From isolating agent workspaces to avoiding conflicts and connecting to scheduled execution, organized from real work.

antigravity³⁵⁰ worktree² multi-repo² agent-design² automation⁴²

✦ Premium Article

When you open several repositories in one editor, telling an agent "touch only this repository" turns out to be harder than expected. If two agents run on the same working directory, one's writes break the other's assumptions. As an indie developer running four sites in parallel, this was a daily problem for me.

Combining Antigravity 2.0 projects with git worktrees lets you solve this "workspaces bleed into each other" problem structurally. The idea is to align the logical unit (project) with the physical unit (worktree), giving each agent a closed sandbox. This article organizes that layout with the texture of real work.

The whole layout in one line

Before the details, the aim in one line is to "align three things per repository: the logical (project), the physical (worktree), and the permission (lock)."

The unit of work the agent perceives, the directory where files actually live, and the scope of the lock that stops simultaneous writes. When these three are misaligned, parallel operation breaks quietly. When they align, adding agents does not collapse it. From here, we assemble these three layers in order.

Why worktrees

A git worktree is a mechanism for carving multiple working trees out of a single repository. Because you can hold a separate directory per branch, you can experiment in another working tree while touching main, without switching branches.

In agent operation, this pays off. In an environment where files get rewritten every time you cross branches, the footing of parallel agents is unstable. Carve a worktree and each agent sees only its own dedicated directory.

# Carve working trees out of one repository
cd ~/repos/antigravitylab.net
git worktree add ../wt/antigravity-feature-a feature-a
git worktree add ../wt/antigravity-feature-b feature-b
 
# Inspect the carved trees
git worktree list

Now feature-a and feature-b exist in separate directories. Writing files in one is unrelated to the other. Only the .git substance is shared; the working files are fully separated.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦A layout that physically isolates agent workspaces with projects and git worktrees

✦The conflicts that arise when several agents run in parallel, and the implementation to avoid them

✦The traps I actually hit in parallel operation, and the operating rules I settled on

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

Align projects with worktrees

An Antigravity 2.0 project is the logical unit of work the agent perceives. The crux here is to assign one worktree per project and keep the two one-to-one.

I fix this correspondence with a naming convention.

Derive the worktree path from the repository name and feature name (e.g. wt/antigravity-feature-a)
Create the Antigravity project with the same name
Pin the project root to that worktree's directory

As long as you do not break these three steps, "which project touches which directory" is uniquely determined. Conversely, exposing multiple worktrees from one project forces the agent to decide, leaving where it should write ambiguous. Keeping it one-to-one is the premise of parallel operation.

Avoid conflicts between agents

Worktrees separate working files, but conflicts through the shared .git remain. A representative one is the index lock when several agents hit git at once.

# A wrapper that commits safely in each worktree
safe_commit() {
  local wt="$1" msg="$2"
  cd "$wt" || return 1
  # a simple lock that serializes parallel git ops on the same repo
  local lock="$(git rev-parse --git-common-dir)/agent.lock"
  exec 9>"$lock"
  flock 9                      # wait until other agents finish
  git add -A && git commit -m "$msg"
  flock -u 9
}

With flock I take a lock per .git common directory and serialize parallel commits to the same repository. Even with separate worktrees the .git is shared, so without serializing here the index occasionally corrupts. Before I added this, on a day I ran several agents at once, I hit index corruption exactly once, and have settled on this shape since.

The point is to scope the lock to "per repository." Locking all worktrees together loses concurrency. Identify the common directory with git rev-parse --git-common-dir and serialize only operations belonging to that repository, and agents of other repositories do not stop.

Connect to scheduled execution

Antigravity 2.0 has background scheduled execution. I run it on top of the worktree layout. Each scheduled task completes within its own project (= worktree) and leaves its result on a branch when done.

Where I tripped on the connection was worktree cleanup. Let the temporary worktrees a task created pile up without removing them and git worktree list swells fast, growing orphans that need prune.

# Cleanup at task end (sweep orphan worktrees)
cleanup_worktree() {
  local wt="$1"
  git -C "$wt" worktree remove "$wt" --force 2>/dev/null
  # sweep metadata of worktrees whose references are gone
  git -C ~/repos/antigravitylab.net worktree prune
}

worktree remove deletes the working tree and worktree prune sweeps the dereferenced metadata. Put these two in every task's teardown and you prevent .git/worktrees from bloating. Unglamorous, but for machinery that runs every day, the presence of this cleanup decides the state a month later.

The operating rules I settled on

Finally, a few rules I settled on with this layout.

Keep worktrees short-lived. Delete them when the task finishes. Let them live long and the branch state and working-tree contents drift apart.
One worktree per project. Break this and the agent's write target turns ambiguous.
Serialize git operations on the same repository with a lock. Never forget that even with separate worktrees, .git is shared.
Do not over-raise parallelism. For me, capping at two concurrent agents per repository was the right balance between conflict and throughput.

The virtue of this layout is that it grants agents "freedom" while keeping that freedom from leaking elsewhere. Inside a closed sandbox, an agent can move boldly. A non-leaking design is exactly what widens the range you can entrust with confidence. After running parallel operation for a while, that is how I have come to think.

Start by carving two worktrees from one repository and running separate work simultaneously. The reassurance of things not mixing teaches the value of the design best.

Thank You for Reading

Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.