git-ai: a version control server built for agents, not for branches

An independent implementation of a published design

The starting point is a blog post rather than a feature list. Anthropic built Scion, a faster version control system for coding agents, and described it in an article called Redesigning source control. Scion is internal to Anthropic and is not available to the public, so git-ai is an open source implementation of the design that was described there.

The article frames the problem in terms of workload. Classic Git hosting was built for people who clone a repository, work for hours and push once. Coding agents do something else entirely: thousands of short lived tasks, each touching a few files, each wanting to land in seconds, all on the same branches. Under that load, full clones, merge queues and client side history walks become the bottleneck, according to the project's own explanation.

The answer is to move the work to the server. Clients stay online and fetch only what they need, history questions are answered and cached by the server, changes land through a compare-and-swap instead of waiting in a queue, every update is an entry in a changeset log, and the repository state lives in a consistent database plus object storage so that servers scale out.

Two promises in the README are worth noting because they shape what you can build on top. The project is vendor neutral: the server never calls a language model, and every AI feature works with any provider or with none. And normal Git repositories sit underneath, so the storage is not exotic.

Landing without a merge queue

The core of the design is the landing path, and it is implemented in a component called UserLand. A change is rebased onto the current tip of the branch and then landed with a compare-and-swap, which means the landing succeeds only if the reference still points where the client expects. If two agents land at the same moment, the concurrent lands are batched into a single reference update rather than serialised through a queue.

The difference from a merge queue is not a matter of degree. A queue decides the order of landings in advance and processes them one at a time, which adds latency proportional to the queue and requires the server to understand the content of each change. A compare-and-swap makes the reference update atomic and lets the server arbitrate. The project also documents a dedicated page on landing and batching, which suggests the details of that arbitration are the interesting part.

Conflict handling is not baked into the landing path. A conflicting land is resolved by a resolver that you choose: any LLM provider, a deterministic tool, or none at all. The choice is made through a versioned, vendor neutral protocol, and the documentation treats the absence of a resolver as a legitimate configuration rather than a gap. That framing is the practical answer to the question of what happens when you do not want an automated conflict resolver rewriting your code, and it is worth reading RESOLVE.md before turning the feature on.

History moves to the server and becomes derived data

Under the classic model, blame, log and search are operations the client performs by walking history locally, and every client repeats that work. The Scion design inverts that. Source control is treated as an API, and history runs on the server.

In git-ai, blame, path history, ancestry and code search all run server side and are memoized as derived data, computed once per commit. The word computed once per commit is doing real work in that sentence, because it turns a per-client question into a per-commit artefact. The documentation has a separate page for derived data, so the storage and invalidation rules are set out somewhere in more detail than the summary here.

This is the design that answers the client side history walk complaint directly, and it pairs with the always-online client model. An ObjectService serves single objects and sparse trees, and the graft clone and graft sparse commands materialize only the paths you ask for. For a monorepo where an agent touches a handful of files, downloading a sparse tree instead of a full clone is the difference between a task that lands in seconds and one that does not.

The extension names are consistent throughout. The configuration section is called graft, the command line tool is the graft CLI, the Go code lives under internal/graft, and the documentation sits in doc/graft.

A write-ahead log, a reference lock, and packs in object storage

The storage core follows the design in the article, and it is the part that has to be right for everything else to work.

Each change is a changeset in a write-ahead log held in SQLite or PostgreSQL, with a compare-and-swap per reference. The packs, meaning the Git objects themselves, live in object storage, and the documentation names file, S3, GCS and Azure as the options. Server nodes are caches that any node can rebuild, which is what lets you add nodes to scale rather than shard them.

The consequence of that layout is that the server is stateless in the important sense. A node that dies holds nothing that cannot be reconstructed, and adding capacity is a matter of pointing a new node at the same database and the same object storage.

The storage migration is a two step process, and the documentation is specific about it. You start in shadow mode, import your repositories, and then switch to authoritative. The shadow mode presumably keeps the local Git repositories as the source of truth while the new core catches up, and authoritative hands the role over. Both the storage page and the configuration reference describe this, and the transition is the riskiest operation in the project, so it belongs at the top of your evaluation list.

For local development, the recommended setup is a file backed object store, so the whole architecture can be exercised on one machine before any cloud service is involved.

Verification, review and agent identity are part of the model

Three features treat agents as first class citizens rather than as clients that happen to be fast.

The first is verification. graft-verify tests the tip of a branch, bisects a failure and reverts the change that broke it. With many agents landing small changes, a broken build is hard to attribute, and a bisect-and-revert path turns that into a mechanical operation instead of an argument.

The second is review, and it is different from ordinary approval counts. Reviews support semantic approval rules, so a comment-only change can need fewer approvals than a change to logic. The point is to reserve the scarce human attention for the changes that can break behaviour.

The third is identity and observation. Agents follow the changeset stream and report what matters to each component, through Slack among other channels, and these monitoring agents are nicknamed superfans in the project. Separately, each agent gets its own token, an RPC allowlist and branch policies that decide what it may do, so a compromised or misbehaving agent has a bounded surface.

Caching has the same spirit. graft-cache caches immutable objects in daemon and regional tiers, and it verifies every object rather than trusting the tier that served it, which is the property you need when a cache is fed by hundreds of writers.

Building it, and the shape of the quickstart

The requirements are specific: Linux or macOS, Go 1.26, a C toolchain, and Meson and Ninja, because the build compiles a bundled Git rather than calling a system Git. The module is declared in go.mod as github.com/feder-cr/git-ai with go 1.26.0, and the dependency list shows the storage backends and the service plumbing in the open: the Google, Azure and AWS storage clients, a SQLite driver and a PostgreSQL driver, gRPC middleware, Prometheus instrumentation, a JWT library and a YAML parser.

The build itself is one command:

git clone https://github.com/feder-cr/git-ai.git
cd git-ai
make build

That produces the server, the CLI and the tools into a _build directory. The repository ships a quickstart script that sets up a server, a cache daemon, two agents and a landing in a temporary directory, which is the fastest way to see the whole design work end to end:

examples/graft/quickstart.sh

The CLI is the binary that script leaves you with:

./_build/bin/graft

To run a server of your own, the documentation says to adapt the example configuration and start the server with it:

examples/graft/config.toml

_build/bin/gitaly serve config.toml

The binary name is a legacy of the project history, since the codebase descends from Gitaly, and the Makefile still carries that project's install layout, with a PREFIX defaulting to /usr/local and separate prefixes for the server binaries and for the self built Git.

The project is young. It released v0.1.0 on 2026-10-15 and v0.2.0 on 2026-10-18, and the last push was on 2026-10-19. The README describes it as MIT licensed, and the repository root carries a LICENSE file and a separate NOTICE file, which you should read together before you embed it in a product.

Editorial conclusion

git-ai is worth evaluating if your bottleneck is landing many small changes from many agents onto shared branches, because the compare-and-swap path and the server side history are aimed squarely at that problem. It is not a drop-in replacement for a hosted Git service, it needs Go 1.26 plus a C toolchain, Meson and Ninja because it compiles a bundled Git, and it is two releases old. Before you plan a migration, read ARCHITECTURE.md and STORAGE.md, run the quickstart script on a scratch repository, and confirm that the shadow then authoritative storage transition behaves the way your deployment expects before you point it at a real one.

Frequently asked questions

Official sources

1. feder-cr/git-ai on GitHub
2. Issues
3. Project website
4. README
5. Releases