git-ai: Zwei Tage bis zu tausend Sternen – Open-Source-Remake von Anthrpic's Scion

Am 13. Oktober veröffentlichte Anthropic einen Engineering-Blogartikel, in dem es zum ersten Mal öffentlich über sein internes Versionierungssystem Scion berichtete: Ein zentralisierter Server-System, das für mehrere hundert gleichzeitig lesende und schreibende Code-Agenten entwickelt wurde, jedoch nicht quelloffen ist. Zwei Tage später, am 15. Oktober, erstellte der Entwickler feder-cr (Federico Elia) auf GitHub die git-ai-Repository, wobei der erste Satz des README-Textes lautete: „Anthropic hat Scion entwickelt… Also habe ich git-ai entwickelt: Eine quelloffene Version dieses Designs, die von jedem ausgeführt werden kann.“ Bis zum 17. Oktober waren es etwa 1.000 ★ (gemessen an der GitHub-Such-API mit 1057), in zwei Tagen wurden insgesamt tausend Sterne erreicht. MIT-Lizenz, Go-Programmiersprache. Der Artikel wird wie gewohnt in sechs Abschnitte aufgeteilt.

1. Wer ist es?

Die Identität von gitai muss in zwei Ebenen betrachtet werden.

Der Sockel ist eine Fork von GitLab Gitaly. Gitaly ist der Git RPC-Server von GitLab. Diese Beweisfolge ist im Repository sehr offensichtlich: Das NOTICE-Dokument beginnt mit „The following components are included in Gitaly:“, im cmd/Ordner befinden sich die vollständige Original-Befehlsauswahl wie gitaly, gitaly-backup, praefect usw. Das VERSION-Dokument zeigt 19.5.0-rc3 (die Versionnummer von Gitaly). Im LICENSE stehen zwei Zeilen Urheberrecht: „Copyright (c) 2026 Federico Elia and the gitai contributors (modifications and additions). / Copyright (c) 2016-present GitLab Inc.“. In dem README steht: Gitaly stellt die zugrunde liegende Git-Infrastruktur bereit, jeder Gitaly-RPC-Request von oben bleibt weiterhin verfügbar; der nicht MIT-orientierte ee/Ordner ist in diesem Repository nicht enthalten.

Das neue Feature wird „graft“ genannt. Lokal: Insgesamt 2833 git-tracked Dateien, Go-Code umfasst etwa 576.000 Zeilen (der größte Teil stammt von Gitaly). Davon entfallen etwa 75.000 Zeilen auf die neuen Ordner internal/graft und cmd/graft*. Das ist der Kern des Open-Source-Projekts: die graft CLI, der graft-cache-Cache-Manager, der graft-verify-Verifier, das graft-bench-Testwerkzeug sowie eine ganzen Reihe von Subsystemen wie land, changeset, derived data, resolver und review auf der Serverseite.

Ein weiterer Detailspunkt, der offenbar sein muss: Die Git-Historie des Lagers wurde zusammengefasst, und bei einem oberflächlichen Clone kann nur ein Commit gesehen werden. Die 75.000 Zeilen neuen Codes können natürlich nicht in zwei Tagen geschrieben worden sein, aber die Entwicklungszeit lässt sich nicht nachweisen. Man kann es daher nur als „langfristige Vorbereitung mit einmaliger Veröffentlichung“ interpretieren. In der Abschnitt „Status“ des README steht: Version 0.1.0, die erste öffentliche Veröffentlichung. Zudem enthält das Lager die Agent-Flow-Dateien AGENTS.md und CLAUDE.md. Das Projekt selbst ist somit nach dem Prinzip organisiert, „für die Agenten zu verwenden und deren Beteiligung an der Entwicklung zu ermöglichen“.

II. Warum jetzt

Der direkte Grund für das Auftreten von gitai ist der Artikel von Anthropic „Redesigning source control at Anthropic“ (veröffentlicht am 13. Oktober, aktualisiert am 15. Oktober). Der Blog hat erstmals die Schwierigkeiten bei der Sourcecode-Verwaltung unter Agenten digitalisiert: Im Mai 2026 waren es durchschnittlich etwa 2.500 Merges pro Tag, im September über 30.000 pro Tag – ein Zuwachs von 12-fach innerhalb von vier Monaten. Die historische Daten im monorepo betragen fast 100GB, die komprimierten Arbeitskopien beginnen bei 25GB. Jeden Tag werden etwa 25 Millionen CI-Checks ausgeführt, was einem Git-Datenaufkommen von 600PB+/Tag entspricht. In den Spitzenzeiten müssen mehrere internes Git-Mirrors betrieben werden. Traditionelle Git-Verwaltungssysteme sind für „jemanden, der einmal klonert, ein paar Stunden arbeitet und einmal pusht“ konzipiert – die vollständige Klonierung, die Merging-Kette und die historische Durchsuchung des Clients werden auf dieser Ebene zu Engpässen. Die Lösung von Scion besteht darin, die Arbeit auf Servern zu verlagern: Der Client bleibt immer online und holt nach Bedarf ab; historische Probleme (Blame, Path-History) werden auf dem Server berechnet und gespeichert; ohne Warteschlangen wird der Compare-and-Swap-Verfahren angewandt; auf dem Server gibt es keine vollständigen Repository-Kopien, alles kann horizontal skaliert werden. Anthropic hat die Migration in 5 Monaten abgeschlossen.

Aber Scion ist intern und nicht für die Öffentlichkeit zugänglich. Deshalb gibt es diese Welle der Open-Source-Remakes. Gitai ist nicht der einzige (Schon am 13. Oktober gab es jemanden, der openscion erstellt hat, aber seine Verbreitung war gering, und die HN hatte nur 7 Likes). Aber Scion ist der schnellste.

Die andere Seite dieser Popularität kommt von einem Streit. Am 14. Oktober veröffentlichte der ehemalige Teammitglied des Source Control-Systems von Meta, sunshowers, einen Beitrag (HN 425▲), in dem er behauptete, dass Scion „ stark von Mononoke inspiriert“ sei (Meta’s Open-Source-Version des Source Control-Systems): Es gibt ähnliche Konzepte und Begriffe wie derived data, Bonsai changeset usw., sogar der Name „Scion“ ist eine Umkehrung des Wortlauts von „Bonsai“ ohne das „B“. Der Blog von Anthropic dankte damals nur Google Piper und Meta Sapling. Am 15. Oktober fügte er einen zweiten Beitrag hinzu (HN 251▲), in dem er ausdrücklich bestätigte, dass Scion „absichtlich und offensichtlich Mononoke kopiert“ sei und es eine Personenkollision gebe (dies ist eine Aussage von sunshowers, die nicht unabhängig überprüft wurde). Später berichtete Nick G. von Anthropic auf HN, dass der Blog eine Erklärung über die Herkunft hinzufügte und oben auf der Seite ein offizieller Satz „Update“ stand: „Am 15. Oktober aktualisiert, um mehr Details über die Projekte zu geben, die viele der Techniken, die wir in Scion verwenden, entwickelt haben.“ Die HN-Story des Hauptblogs hat die Nummer 889▲ und war in dieser Woche das Hauptthema im Engineering-Forum.

Dieser Streit hat für das Objekt der Analyse folgende Bedeutung: Er hat die Idee, dass „der Designansatz von Scion in Wirklichkeit bereits ein Beispiel für Open-Source-Software ist (Mononoke)“, zu einem öffentlichen Thema gemacht. Damit wurde eine Marktaufklärung für alle Nachahmungsprojekte erreicht. Genau diese Chance hat gitai genutzt.

III. Mechanismusanalyse

Das Design, das in dem Blog von Scion beschrieben wurde, wurde schrittweise in funktionierende Produkte umgewandelt. Nennen Sie vier der wichtigsten Punkte.

Das erste ist, dass keine Warteschlangen entstehen. Die konventionellen Hosting-Plattformen haben serielle Engpässe in ihren Kombinierungsprozessen. Bei UserLand wird die Änderung auf den aktuellen Branch-Tip rebase-t, anschließend wird mit „compare-and-swap“ die Referenz aktualisiert: Ein Scheitern des CAS-Prozesses bedeutet, dass jemand vorzeitig die Änderung umgesetzt hat. Die Prozedur wiederholt sich automatisch, standardmäßig bis zu 20 Mal. Konkurrierende Umsetzungen auf demselben Branch werden ebenfalls in einer Batch-Operation als eine einzige Referenzaktualisierung umgesetzt. Die Basiskennzahlen im Dokument verdeutlichen die Situation: Wenn 20 Agenten auf denselben Branch umsetzen, müssen die Änderungen durchschnittlich etwa 10 Mal versucht werden, mit einer p99-Verzögerung von 26 Sekunden.

Der zweite Punkt ist der Changeset-Log. Jede akzeptierte Referenzänderung wird in einen changesets.jsonl für jeden Repository eingetragen. Die Daten werden seriell hinzugefügt mit flock und anschließend mit fsync gesichert. Der letzte Eintrag, der bei einem Kollaps beschädigt wird, wird beim nächsten Hinzufügen abgeschnitten. Die Nummern beginnen bei 1 und steigen dicht an. Der Agent kann diesen Stream abonnieren, um in Echtzeit zu sehen, was im Repository vor sich geht. In der README-Datei wird solche Überwachungsagenten „superfans“ genannt. Zudem können wichtige Informationen per Slack übermittelt werden.

Der dritte Punkt betrifft die auf Servern generierten Daten. Blame, Pfadhistorie, Abstammungsbeziehungen sowie Code-Suche werden alle auf dem Server berechnet. Es wird eine nach Inhalt adressierte Cache-Verwaltung verwendet, wobei der Schlüssel SHA-256(kind, commit, path) ist. Die Schreibvorgänge erfolgen über temporäre Dateien mit atomarer Ersetzung durch Rename. Jeder Commit wird nur einmal berechnet. Der Client benötigt daher keine vollständige Historie. graft clone und graft sparse speichern lediglich den gewünschten Pfad.

Der vierte ist ein einsetzbarer Konfliktlöser. Das Protokoll ist versioniert und vendorneutral: Es kann mit einem lokalen Befehl (stdin für JSON-Eingaben) oder einem HTTP-Punkt verwendet werden. Dabei können eine Liste der zulässigen Pfade, eine Liste der verbotenen Pfaden, eine Liste der Akteure, Zeitüberlauf und die maximale Anzahl an Dateien festgelegt werden. Der AI-Konfliktlöser läuft außerhalb des Servers – der Server selbst ruft niemals auf große Modelle zu. Dies ist eine wichtige Voraussetzung für vendor-neutralität, wie im README wiederholt betont wird. Die von dem AI-Konfliktlöser gelösten Commits werden mit der Anmerkung „Graft-Resolved-By“ versehen, damit sie nachträglich überprüft werden können.

Auf dem Sicherheitsmodell gibt es einen Punkt, der erwähnt werden sollte: Jeder Agent hat seinen eigenen Token, die Identität kann nicht von internen Benutzern ID’s getäuscht werden. Dies wird durch e2e-Tests sichergestellt; welche RPC’s der Agent abrufen darf, ist in den Code eingetragen in einer „Allowlist“. Gefährliche RPC’s wie das Erstellen von Repositorys aus Snapshots sind für den Agenten immer ausgeschlossen.

Es gibt noch zwei zusätzliche Mechanismen. Erstens die Überprüfung nach dem Implementieren: graft-verify sorgt dafür, dass eine „grüne Referenz“ erstellt wird. Wenn die Testung nach der Implementierung fehlschlägt, werden die verursachenden Änderungen identifiziert und automatisch zurückgesetzt. Zudem wird eine Fußnote mit „Graft-Auto-Revert“ hinzugefügt. Ein Höchstwert pro Stunde schützt vor wiederholten Fehlern. Dadurch hat der Slogan „Zuerst kombinieren, dann testen“ sich in einen Prozess mit Rückkehrfähigkeit verwandelt. Zweitens die semantische Review-Regelung: Die Genehmigungsanforderungen können je nach Art der Änderung angepasst werden. Beispielsweise benötigen reine Anmerkungsänderungen weniger Genehmigungen als logische Änderungen. Dies ist wichtig für die Situation, in der Agenten massenhaft Änderungen einreichen – schließlich ist die Aufmerksamkeit menschlicher Reviewer eher knapp. Im Caching-System gibt es einen separaten Prozess namens graft-cache. Die Caches im Bereich sind unveränderliche Objekte; vor jedem Zugriff auf ein Objekt wird der ID neu berechnet (Typ plus Länge plus Inhalt). Wenn dieser nicht übereinstimmt, wird der Zugriff abgelehnt. Eine Gruppe von Misserfolgen wird zu einem einzigen Aufruf nach oben zusammengefasst.

IV. Zahlen und Verifizierung

Das mitgelieferte Bench-Dokument des Lagers zeigt eine praktische Messung: 100 Agenten setzen gleichzeitig auf einen Branch. Die Maschine verwendet Intel Core Ultra 7 255H und WSL2; das Dokument gibt den Störgeräuschen selbst an. Wenn die Batch-Einstellung deaktiviert wird, erfolgt eine durchschnittliche Anpassung 56,94 Mal. Von 500 Anpassungen werden nur 115 erfolgreich umgesetzt, 277 werden aufgegeben. Die Durchsatzrate beträgt 126,6 Mal pro Minute. Wenn die Batch-Einstellung aktiviert wird, sinkt die Anzahl der Versuche auf durchschnittlich 1,00 Anpassung pro Minute. Dabei werden 392 Anpassungen umgesetzt, mit einer Durchsatzrate von 257,6 Mal pro Minute.

Was noch schwieriger ist, ist, dass es keine einzige positive Meldung gibt. Im selben Dokument steht, dass die Zertifizierungsstandards für Phase 4a nicht erreicht wurden: Bei 50 und 100 Agenten-Mengen war die p99-Verzögerung höher als ohne diese Mengen. Die Status-Seite des README-Kapitels sagt auch direkt, dass dies die erste offizielle Version 0.1.0 ist. Die Schnittstellen könnten vor 1.0 ändern, die End-to-End-Tests wurden nur auf einer einzigen Maschine durchgeführt, das Verhalten mehrerer Knoten sind noch nicht getestet. Im Dokument „doc/graft“ werden vier Einschränkungen aufgelistet: Es handelt sich nicht um eine Hosting-Lösung, es ist kein Ersatz für GitLab, es ist keine Implementierung von Scion und es stellt keine Sicherheitsgrenzen dar.

Vergleichen Sie die gängigen Praktiken in der Branche: Die meisten Projekte, die innerhalb von zwei Tagen tausend Sterne erreichen, haben nur ein Visionbild im README. Dieses Projekt wurde mit sechs Phasen des Designs, Fuzz- und Crash-Recovery-Tests sowie einem Bench-Report veröffentlicht, der ehrlich „Nicht abgenommen“ besagt. Die Qualität des Projekts ist die stärkste unter den Kopien.

Fünf, Beurteilung

Zuerst zur Schlussfolgerung: Gitai ist eine interessante Option, aber sie löst momentan das Problem der „Anthropic-Größe“. Zudem behauptet Anthropic selbst in seinem Blog, dass die meisten Organisationen diese Probleme nicht in nächster Zeit zu bewältigen haben.

Drei Beobachtungen. Erstens: Die Fenster, die es berührt, sind zur Hälfte technisch, zur Hälfte narrativ. Der Streit um die Zugehörigkeit von Mononoke hat „dieses Design bereits mit einem Beispiel für Open-Source-Entwicklung“ zum öffentlichen Thema gemacht, was gleichbedeutend ist mit einer Marktaufklärung für alle Nachahmungsprojekte. Gitai ist das schnellste in dieser Welle – innerhalb von zwei Tagen wurden etwa 1.000 Sterne vergeben, viel mehr als bei openscion vom 13. Oktober (mit nur 7 Likes). Ein großer Teil der Beliebtheit geht auf die Kontroverse um Anthropic zurück, nicht ausschließlich auf das Produkt selbst.

Zweitens ist die Wahl des Gitaly-Fork-Basiskits sehr kluge und auch anspruchsvolle. Klar ist, dass es die komplexen Aufgaben wie Git-RPC, Repository-Verwaltung und Backup direkt übernimmt. Die MIT-Lizenz und die Aussagen sind ebenfalls sauber formuliert. Anspruchsvoll ist jedoch die Tatsache, dass es nun mit der Komplexität des GitLab-Ökosystems belastet wird. Die Erstellung erfordert Meson, Ninja sowie komplexe Kombinierungen von Quellcode, was den Einstieg erschwert. Deshalb wird es in der kurzen Zeit wohl nicht als allgemeines Werkzeug dienen.

Drittens: Was wirklich wertvoll ist, um zu lernen, sind einige Designentscheidungen statt des Codes selbst: Für den Einsatz auf dem Client verwenden wir CAS in Kombination mit Batch-Operationen statt Queues, für Logs verwenden wir eine Erweiterbare JSONL-Datei mit fsync, die AI-Funktionen werden als drahtlose Lösungen außerhalb des Servers implementiert, und Identitäten sowie Berechtigungen der Agenten sind im Protokoll festgelegt. Diese vier Punkte sind eine kostenlose Antwort für jede Gruppe, die mit mehreren Agenten zusammenarbeiten möchte.

Das Risiko muss klar erklärt werden: Einzelpersonale Führung, die Geschichte wird verdeckt, der Entwicklungsprozess ist nicht sichtbar, die API für 0.1.0 kann jederzeit ändern, selbst die eigenen Tests haben nicht bestanden. Es ist fairer, es nach „hohem designbezogener Wert, aber zweifelhafte Produktivität“ einzuordnen.

Sechstes, Wer kann wie verwendet?

Mehrere Agenten, die gleichzeitig in einem Repository schreiben, haben bereits Konflikte und sind mit dem Queue blockiert. Das ist ihr primäres Publikum. Mit dem Quickstart-Skript kann man mit einer Handvoll Klicks einen Server starten, den Caching-Prozess einrichten, zwei Agenten hinzufügen und einmalig eine Implementierung durchführen. In einer halben Stunde kann man den Hauptprozess erledigen. Das Plattform-Engineering-Team kann nur lesend auf die vier Dokumente ARCHITECTURE, STORAGE, RESOLVE und LIMITATIONS unter doc/graft zugreifen und die Designentscheidungen in seine eigenen Pläne übernehmen, ohne Code einzuführen. Ein normales Einzelrepository-Team kann problemlos weiterhin mit Git arbeiten – das sagt auch dieses Repository selbst.

Wer handeln will, sollte sich an drei Dinge erinnern: Das Speicherkernmodul ist standardmäßig deaktiviert; importieren Sie aus dem Shadow-Modus und wechseln Sie anschließend auf den Authoritative-Modus; Konfigurieren Sie zunächst die entscheidenden Tools für den Resolver, den AI-Resolver fügen Sie erst zum Schluss hinzu; Betrachten Sie es nicht als Sicherheitsgrenze – beschreiben Sie die Einschränkungen klar.

Quelle der Informationen

• Hauptteil des Lagerraums: github.com/feder-cr/git-ai (README, NOTICE, LICENCE, go.mod, VERSION, lokaler Clone-Test am 17.10.; Dokumente unter ARCHITECTURE/STORAGE/RESOLVE/LIMITATIONS/BENCH/LAND-BATCHING)
• Offizielle Blogseite von Anthropic „Redesigning source control at Anthropic“ (veröffentlicht am 13.10., aktualisiert am 15.10.; alle Zahlenbezeichnungen bei Scion)
• Zwei Artikel von sunshowers.io über die Frage der Zugehörigkeit zu Mononoke (14.10., 15.10.) sowie Diskussionen auf HN (889▲/425▲/251▲/7▲, Morgen-Snapshot am 17.10.)
• Anzahl der Sterne und Erstellungszeit: GitHub-Such-API und createdAt der Repository-Seite (Morgen-Snapshot am 17.10., die Anzahl der Sterne ändert sich weiterhin)