Git wasn’t built for a thousand
committers who never sleep.
Anabranch is a version control layer that sits underneath the repo you already have. Agents get isolated workspaces in milliseconds, conflicts they can work through instead of stall on, and an undo that actually undoes. Your team keeps Git and GitHub, exactly as they are.
Built on Jujutsu · Git-native on both ends · No migration required
- main8f2c1ad
- feat/billing-v2open PR #4471
- fix/session-leakopen PR #4468
Ordinary Git. Nothing to learn, nothing to migrate.
- 1,284 workspaceslive
- operation logrestorable
- merge queue12 landing
One repo. Every state addressable and reversible.
- agent-0412clean · landing
- agent-0413conflict · isolated
- agent-0414clean · in review
A conflict parks one change. It doesn't stop the line.
Version control was the last thing anyone expected agents to break.
Git is a superb piece of engineering built on an assumption that stopped being true: that a person is sitting there. Every escape hatch it offers — resolve this conflict, name this branch, check out this tree, remember what you did — assumes a human in the loop with judgment and patience. Teams running coding agents in earnest are discovering the same four walls.
A conflict is a stop-the-world event
Git resolves a conflicted merge by handing a human a broken working tree and waiting. An agent that hits one either stalls until somebody notices or invents a resolution nobody reviewed. At fleet scale you get both, constantly.
Branch names are a flat global namespace
Refs were designed for the dozen branches a team carries in its head. Point a fleet at them and you get name collisions, tens of thousands of orphaned refs, and no way to answer “what is run 412 actually working on right now?”
Every workspace is a full clone
A serious monorepo is tens of gigabytes. Multiply that by every concurrent run and the bottleneck stops being the model and starts being checkout time — paid for in wall-clock latency and in CI minutes, every single attempt.
There is no atomic undo
The reflog recovers a ref. It does not restore the working tree, the index, and every ref together, to a known-good moment, in one command. That is the exact primitive you need when a machine is committing thousands of times an hour.
None of this shows up as “we have a Git problem.” It shows up as a CI bill that tripled, a merge queue six hours deep, and a fleet of very expensive agents waiting on each other.
Your trunk stays the main channel. Agents run the anabranches.
Replacing version control at a company that ships is a multi-year migration nobody has budget for. So we don’t ask for one. Work leaves the main channel, runs in parallel where it cannot collide with anything, and rejoins downstream as ordinary Git commits. Either side can be switched off tomorrow without stranding a single one of them.
- 01
Point it at the remote you already have
Anabranch mirrors your Git repository into a change-addressed store and keeps the two in sync, both directions, continuously. Nothing on GitHub moves. Nobody on your team changes a single command they type.
$ anabranch link github.com/acme/monorepo → mirrored 1.2M commits · sync live · 41s - 02
Agents get workspaces, not clones
A virtual filesystem materializes only the files a run actually opens. Cold start is milliseconds at any repo size, and a thousand concurrent workspaces cost roughly what one checkout used to.
$ anabranch ws create --agent agent-0412 → workspace ready in 38ms · 0 bytes fetched - 03
Conflicts become data, not a dead end
A conflict is recorded inside the change rather than dumped into a broken tree. The agent keeps working, the queue lands everything provably clean, and the one contested change is parked with both sides intact for a human or a resolver to settle.
$ anabranch queue status → 11 landed · 1 parked (conflict) · 0 blocked
The primitives an autonomous committer actually needs.
First-class conflicts
A conflict is a value stored in the commit, not a wedged working directory. Work continues past it and gets resolved on its own schedule.
Operation log & atomic undo
Every mutation to the repository is an entry in an append-only log. Restore the entire repo — tree, index, refs — to any prior moment with one command.
Stable change identity
A unit of work keeps one ID through every rebase, amend, and squash. You can follow what run 412 did without chasing hashes that no longer exist.
Virtual workspaces
Lazy, content-addressed materialization. A workspace on a 40GB monorepo opens in milliseconds and fetches only what gets read.
Speculative merge queue
Candidate merges are evaluated in parallel rather than serialized. Clean work lands immediately instead of queueing behind an unrelated failure.
Semantic conflict detection
Agents produce mechanically similar diffs that merge cleanly line-by-line and break at the type level. We check the build graph, not just the text.
Per-change provenance
Which run, which model, which prompt, which tool call produced this hunk — attached to the change itself and queryable long after the PR is closed.
Git-native on both ends
Two-way mirroring with your existing remote. Your team's clients, hooks, CI, and code review keep working untouched.
| At agent scale | Git alone | With Anabranch |
|---|---|---|
| Hitting a conflict | Working tree wedged; run halts for a human | Recorded in the change; the run continues |
| Workspace cold start | Full clone, minutes on a large repo | Virtual mount, milliseconds at any size |
| Undoing a mistake | Per-ref reflog, lossy, no tree restore | Whole-repo restore to any logged operation |
| 1,000 concurrent lines of work | Flat ref namespace, collisions, orphans | Anonymous changes with stable IDs |
| Merge queue behaviour | Serialized; one failure blocks the line | Speculative; clean changes land in parallel |
| What your developers use | Git | Git |
The reasonable objections.
- Do we have to migrate off Git?
- No, and we think you shouldn't. Anabranch mirrors your existing repository two ways and keeps GitHub as the source of truth for humans. Every change an agent makes lands as an ordinary Git commit on an ordinary branch. If you turn Anabranch off tomorrow, your history is intact and nothing is stranded.
- Why not just adopt Jujutsu directly?
- You should look at it — it's excellent, and Anabranch is built on it. What jj gives you is a client: a better model of changes, conflicts, and history on one developer's machine. What it doesn't ship is the server side of a fleet — virtual workspaces, a speculative merge queue, provenance, quota and permissions across thousands of concurrent non-human actors. That's the part we build.
- What about Piper, or Sapling?
- Piper and Fig are internal to Google and have never been licensable, though they got a great deal right about virtual clients twenty years early. Sapling is a genuine option and we've learned a lot from its filesystem work. We bet on Jujutsu because it is already Git-backed, which is what makes running alongside your existing repo nearly free rather than a rewrite.
- Does this replace our merge queue?
- It can, and that's usually where teams see the first week's payback. It can also sit behind the queue you already run and simply feed it changes that are known to be clean.
- Where does it run?
- Managed on Google Cloud, or self-hosted inside your own VPC for teams whose source can't leave their perimeter. The storage layer is content-addressed blobs and the control plane is stateless, so a self-hosted deployment is genuinely the same software.
- How do we know what the agents actually did?
- Every change carries the run, model, and tool calls that produced it, and the operation log records every mutation to the repository in order. Reviewing a fleet's week is a query, not an archaeology project.
If your agents are already stepping on each other, we want to talk.
We’re working with a small number of teams running coding agents against a real repository at real volume. Design partners get hands-on setup, direct access to us, and a say in what gets built next.
Pre-seed, pre-launch, building in the open. Anabranch is developed on top of Jujutsu, which is open source under Apache 2.0 and not affiliated with us.