In diesem Beitrag
git-ai: Parallele Agenten-Merges und Verifikation
git-ai, veröffentlicht als feder-cr/git-ai und kurz gitai genannt, ist ein Versionskontroll-Backend für parallel arbeitende Coding-Agenten. Es verlagert Repository-Operationen auf einen Server und bündelt Änderungen, die denselben Branch erreichen. Für die Einführung ist entscheidend, ob dein Team die Wartezeit bis zur Integration verkürzen und dabei belastbare Prüfergebnisse für genau die Revision behalten kann, die es veröffentlicht.
Einen Patch zu erzeugen, ihn in einen Branch aufzunehmen und nachzuweisen, dass das entstandene Produkt funktioniert, sind unterschiedliche Schritte. gitai stellt Mechanismen für die Integration und für die Prüfung ausgewählter Ergebnisse bereit. Euer Entwicklungsablauf muss diese Schritte weiterhin miteinander verbinden.
Quellen geprüft am , Commit 6b0ab81e6e37. Die geprüfte README bezeichnet gitai als Version 0.3.0. Dieser Artikel analysiert Dokumentation und Quellcode. Er beschreibt weder einen Wavect-Produktiveinsatz noch einen unabhängig ausgeführten Performance-Benchmark. Die folgenden Evaluierungsfälle sind unsere Empfehlungen.
Was ist feder-cr/git-ai und wie hängt es mit Scion zusammen?
Die Projekt-README am geprüften Commit beschreibt eine unabhängige Implementierung unter MIT-Lizenz, die sich an Anthropics öffentlich beschriebenem Versionskontrolldesign orientiert. Ausgangspunkt war GitLabs Gitaly-Server. Die ausführbaren Programme und Konfigurationsnamen verwenden weiterhin graft; darunter liegen gewöhnliche Git-Repositories.
Anthropics Engineering-Artikel zu Scion beschreibt Infrastruktur für das außergewöhnlich große eigene Repository und dessen Agentenlast. gitai ist ein eigenständiges Projekt. Die für Scion gemeldeten Infrastruktureinsparungen lassen sich nicht auf gitai übertragen. Wer gitai installiert, installiert damit nicht Anthropics internes System.
| Name | Hauptaufgabe | Relevante Entscheidung |
|---|---|---|
| feder-cr/git-ai, kurz gitai | Repository-Operationen auf dem Server und Integration paralleler Änderungen; die CLI heißt graft | Wie gelangen fertige Agentenänderungen in einen stark genutzten Branch? |
| git-ai-project/git-ai | Zuordnung von KI-generiertem Code zu seiner Herkunft, beschrieben im eigenständigen Projekt-Repository | Welcher Code stammt von einem KI-Werkzeug? |
| Graft für Repository-Kontext | Repository-Karten als Agentenkontext, behandelt in unserem Graft-Review zu Repository-Karten | Wie findet ein Agent den relevanten Code? |
Prüfe den Repository-Inhaber, bevor du einer Installationsanleitung folgst. Die ähnlichen Namen machen die Befehle oder Integrationen nicht austauschbar.
Welchen Engpass löst die Integration paralleler Änderungen?
Landing bedeutet, eine vorgeschlagene Änderung in einen Zielbranch aufzunehmen. Es bezeichnet kein Deployment. Wenn viele Agenten gleichzeitig fertig werden, kann jeder seine Änderung gegen einen Branch-Stand vorbereitet haben, den ein anderer Agent zuerst weiterbewegt. Diese Integration immer wieder neu aufzubauen und zu versuchen, kann selbst zur erheblichen Arbeitslast werden.
Der Leitfaden zur Landing-Implementierung erklärt das Batching: Eine Verarbeitungsspur bündelt innerhalb eines Serverprozesses Anfragen für einen Repository-Branch, integriert sie gegen einen fortgeschriebenen Branch-Stand und veröffentlicht die angenommenen Änderungen über ein Compare-and-swap-Update der Referenz. Dieses Update gelingt nur, wenn die erwartete vorherige Referenz noch übereinstimmt.
Scheduling und eine interne Warteschlange gibt es weiterhin. Entscheidend ist, wie konkurrierende Updates koordiniert werden. Batching gilt für geeignete Standalone-Anfragen; die Dokumentation schließt den in GitLab integrierten Modus ausdrücklich aus. Eine Verarbeitungsspur gehört außerdem zu genau einem Prozess. Zusätzliche Serverknoten erzeugen daher keine gemeinsame Spur über alle Knoten hinweg.
| Beobachtetes Problem | Sinnvolle erste Untersuchung |
|---|---|
| Agenten überschreiben lokale Dateien oder benötigen inkompatible Abhängigkeiten | Isolation von Arbeitsverzeichnissen und Laufzeitumgebungen. Beginne mit unserem Leitfaden zu Worktrees und Jujutsu. |
| Kompatible Aufgaben benötigen eine gemeinsame laufende Anwendung für Feedback | Lokales Zusammenführen und klare Branch-Zuständigkeit, behandelt im GitButler-Leitfaden zum gemeinsamen Workspace. |
| Fertige Änderungen konkurrieren wiederholt um das Update desselben Server-Branches | Landing-Wiederholungen, Ressourcenkonkurrenz und Integrationslatenz messen. Hier liegt der relevante Einsatzfall für eine gitai-Evaluierung. |
| Code lässt sich konfliktfrei zusammenführen, verletzt aber das erwartete Produktverhalten | Verhaltenstests, Abhängigkeitsprüfungen und Freigabenachweise verbessern. Schnellere Referenzupdates belegen keine Korrektheit. |
Wie prüft gitai KI-generierte Lösungen für Merge-Konflikte?
Eine vom Modell erzeugte Konfliktlösung bleibt ein Vorschlag, bis die konfigurierte Verifikation für genau den Tree erfolgreich war, der integriert würde. Das Resolver-Protokoll trennt den Server von einem optionalen Resolver-Befehl oder HTTP-Dienst. Die Konfliktlösung muss aktiviert und angefordert werden. Der Resolver kann deterministische Regeln oder ein Modell verwenden.
Für Modellausgaben muss der Betreiber verify.command konfigurieren und die Verifikation aktivieren. Ohne erfolgreiche Prüfung erhält der Aufrufer ein Konfliktpaket, das den vorgeschlagenen Inhalt enthalten kann. Lösungen aus deterministischen Regeln können ohne diese Verifikation integriert werden; eine aktivierte Prüfung erfasst auch diese Lösungen. Ein eigener Befehl, der ein LLM aufruft, muss als modellbasiert gekennzeichnet sein. Ihn als Regel zu deklarieren, würde seine Herkunft falsch darstellen.
Das entscheidende Implementierungsdetail ist die Identität des Kandidaten. Der Landing-Code vergleicht die geprüfte Tree-Objekt-ID mit dem tatsächlich zusammengeführten Tree. Verändert ein paralleles Update diesen Kandidaten, kann ein früheres positives Prüfergebnis nicht einfach den anderen Tree freigeben.
Ein hypothetisches Beispiel aus der Rechnungsstellung: Agent A benennt eine Funktion zur Summenberechnung um. Agent B ergänzt einen Steuerparameter an der bisherigen Funktion. Ein Resolver kann plausiblen Code erzeugen und dabei die Steuerlogik verlieren. Eine sinnvolle Prüfung enthält deshalb eine Assertion für den Gesamtbetrag einschließlich Steuer. Reines Kompilieren erkennt den Fehler möglicherweise nicht. Ändert ein weiterer Commit anschließend die Rundung, braucht der daraus entstandene gemeinsame Tree Prüfergebnisse, die zu diesem Zustand passen.
Die Verifikationstests des Repositories behandeln unter anderem fehlgeschlagene Prüfungen, Timeouts, veränderte Kandidaten und die Wiederverwendung für einen unveränderten Tree. Das sind hilfreiche Belege für die Implementierung. Wir haben die Tests gelesen, die Testsuite dieses Projekts aber nicht ausgeführt. Ein erfolgreicher Befehl belegt nur das, was dieser Befehl tatsächlich prüft.
Durchläuft ein konfliktfreier Merge automatisch dieselbe Prüfung?
Nein. Die Resolver-Verifikation ist keine allgemeine Testsuite für jede angenommene Änderung. Im geprüften regulären Landing-Ablauf rufen Fast-forwards und konfliktfreie Integrationen den Konfliktlösungs-Verifier nicht auf. Andere konfigurierte Regeln gelten weiterhin.
Ein textueller Konflikt und ein Konflikt im Verhalten sind unterschiedliche Dinge. Ein Agent kann einen Standardwert für Berechtigungen ändern, während ein anderer in einer anderen Datei einen neuen Endpunkt ergänzt. Git kann beide Änderungen konfliktfrei kombinieren, obwohl der neue Endpunkt danach das falsche Zugriffsverhalten zeigt.
Für ein Team, das gitai evaluiert, ändert das die Abnahmefrage. Klärt, in welchen Abläufen eure erforderlichen Prüfungen laufen: bei regulären konfliktfreien Änderungen, deterministischen Lösungen, Modelllösungen und manuell übergebenen Lösungen. Eine erfolgreiche Demo eines KI-gelösten Konflikts belegt noch keine Prüfabdeckung für alle Abläufe.
Was prüft graft-verify nach der Integration?
Das separate Werkzeug graft-verify beobachtet Branch-Updates, stellt einen Branch-Stand lokal bereit und führt den Testbefehl des Betreibers aus. Bei Erfolg aktualisiert es eine grüne Referenz, standardmäßig refs/graft/green/<branch>. Automatische Fehlereingrenzung durch Bisektion und anschließendes Zurücknehmen benötigen eine gesonderte Aktivierung; standardmäßig sind sie deaktiviert.
Damit entstehen zwei relevante Positionen: Der Integrationsbranch kann sich weiterbewegen, während die grüne Referenz einen geprüften Stand bezeichnet. Für Releases empfehlen wir, eine ausdrücklich geprüfte Revision auszuwählen und das Build-Artefakt an sie zu binden. Wer die grüne Referenz liest, danach aber den neuesten main-Stand baut, verliert genau die Unterscheidung, die der Verifier herstellt.
| Schritt | Aufzeichnung | Was sie belegt |
|---|---|---|
| Agentenvorschlag | Ausgangsrevision, eingereichter Commit und Akteur | Die angeforderte Änderung und ihren angenommenen Ausgangszustand |
| Resolver-Verifikation | Tree-ID des Kandidaten, Befehl und Ergebnis | Die konfigurierte Prüfung war für diesen Konfliktlösungskandidaten erfolgreich |
| Angenommene Integration | Zurückgelieferte integrierte Revision und Branch-Update | Die Änderung wurde in das Repository aufgenommen |
| Prüfung nach dem Merge | Geprüfter Branch-Stand, Testergebnis und grüne Referenz | Die gewählten Prüfungen waren für diese integrierte Revision erfolgreich |
| Release | Gewählte Revision, Artefakt-Hash und Release-Freigabe | Euer Auslieferungsprozess verwendet das Artefakt, das aus dem freigegebenen Zustand gebaut wurde |
Die letzte Zeile ist unser Vorschlag für einen verbindlichen Auslieferungsablauf, keine automatische Deployment-Funktion von gitai. Dasselbe gilt für Rollbacks: Quellcode zurückzunehmen macht weder eine Zahlung noch eine E-Mail oder eine destruktive Datenbankmigration rückgängig.
Ein Detail ist für die CI-Integration relevant: graft-verify --once kann sowohl bei einer übersprungenen als auch bei einer erfolgreich geprüften Gruppe von Änderungen den Exit-Status null liefern. Lies das JSON-Ergebnis einschließlich passed, skipped und dem geprüften tip. Ein erfolgreicher Prozessabschluss allein reicht als Freigabenachweis nicht aus.
Ist gitai schneller als GitHub oder gewöhnliches Git?
Der veröffentlichte Landing-Benchmark belegt diesen Vergleich nicht. Die Benchmark-Dokumentation vergleicht aktiviertes und deaktiviertes Batching auf demselben Server. Im hervorgehobenen Szenario reichen 50 Agenten jeweils fünf Änderungen für einen Branch ein; 20 Prozent verursachen absichtlich Konflikte.
Ohne Resolver integriert der Durchlauf mit Batching 200 von 250 Änderungen. Die übrigen 50 sind geplante Konflikte. Ein deterministischer Resolver kann die konstruierten Konflikte der Demonstration bearbeiten. Das misst jedoch nicht, ob ein LLM beliebiges Anwendungsverhalten erhält.
README und Benchmark-Dokument zeigen am geprüften Commit außerdem unterschiedliche Durchsatz- und Latenzbereiche. Deshalb leiten wir daraus keinen plakativ beworbenen Beschleunigungsfaktor ab. Die belegte Aussage ist enger: Batching kann in diesem synthetischen Szenario konkurrierende Wiederholungsversuche reduzieren.
Miss für euren eigenen Vergleich die Zeit von der fertigen Änderung bis zur geprüften Revision, zusätzlich zu Fehlern, menschlichen Eingriffen und Betriebskosten. Beziehe die tatsächliche Testsuite und realistische Dateiüberschneidungen ein. Mehr angenommene Commits pro Minute sind nur hilfreich, wenn Prüfung und Wiederherstellung mithalten.
Was müssen Teams beim Self-Hosting zu Berechtigungen und Code-Weitergabe prüfen?
Das Sicherheitsmodell für Agenten stellt individuelle Agentenidentitäten und Regeln für Referenzen bereit. Das gemeinsame Token bleibt ein Zugang mit Betreiberrechten. In der geprüften Implementierung verwendet das Werkzeug graft-verify für die Prüfung nach dem Merge diesen Betreiberzugang; Agenten können den reservierten Namensraum refs/graft/ nicht direkt ansprechen. Plane eine kontrollierte Release-Anbindung, statt jedem Coding-Agenten die Berechtigungen des Verifiers zu geben.
Das Repository selbst zu hosten legt noch nicht fest, wohin ein Resolver Code sendet. Ein aktivierter externer Resolver kann die freigegebenen Inhalte konfliktbehafteter Dateien erhalten. Legt fest, welche Pfade und Anbieter zulässig sind, auch für Quellcode mit personenbezogenen Daten oder Zugangsdaten. Dabei zählt das dokumentierte Verhalten der Pfadmuster: *.env erfasst verschachtelte .env-Dateien nicht rekursiv. Der Resolver findet und schwärzt nicht automatisch sämtliche Geheimnisse.
Die Implementierung der Prüfung vor dem Landing führt einen konfigurierten Befehl gegen Repository-Inhalte aus. Behandle diese Inhalte als ausführbare Eingaben der Agenten und des Resolvers. Eine reduzierte Umgebung ist keine Sandbox: Isoliere den Runner, entferne unnötige Zugangsdaten, beschränke den Netzwerkzugriff und begrenze den Ressourcenverbrauch. Auch Testausgaben können Daten offenlegen, weshalb Netzwerkbeschränkungen allein nicht ausreichen.
Muss für gitai der bisherige Code-Host ersetzt werden?
Klärt zuerst, welches System den Branch verwaltet und welches für Review, CI und Release zuständig ist. Ein Repository-Backend ist nur ein Teil einer Entwicklungsplattform. Unsere Analyse zur Migration des Code-Hostings behandelt die übergreifende Plattformentscheidung. Hier geht es gezielt um die Annahme und Prüfung von Agentenänderungen.
Die Dokumentation des Review-Subsystems benennt eine wesentliche Grenze: Ein aufgezeichnetes genehmigtes Review macht diese Genehmigung noch nicht zu einer verpflichtenden Landing-Prüfung. Erfordert euer Ablauf eine unabhängige Freigabe, prüft deren Durchsetzung gesondert.
Die Dokumentation des Storage-Kerns unterscheidet einen optionalen Shadow-Modus von einem autoritativen Speicherbetrieb. Sie beschreibt SQLite für einen Knoten und PostgreSQL mit gemeinsamem Objektspeicher für mehrere Knoten. Lokale Git-Repositories müssen weiterhin aus dem Speicher aufgebaut werden und benötigen Plattenkapazität. Ein Wechsel des maßgeblichen Speichers verdient deshalb eine eigene Wiederherstellungsübung.
Einige Überblicksdokumente hinken neueren Implementierungsdetails hinterher. Die aktuelle Storage-Dokumentation beschreibt beispielsweise eine optionale Garbage Collection für Packs, und der Quellbaum enthält Storage-Tests mit mehreren Knoten. Beides rechtfertigt nicht die Annahme, dass euer gewähltes Cloud-Backend, Ausfallszenario oder Produktionsvolumen bereits validiert ist. Fixiert eine Revision und prüft den tatsächlichen Betriebsaufbau.
Wie solltest du gitai vor der Übernahme eines Produktionsbranches evaluieren?
Verwende ein entbehrliches Test-Repository, repräsentative Agentenaufgaben und ausdrückliche Fehlerfälle. Binde noch kein Deployment an, während ihr feststellt, was angenommen, geprüft und wiederhergestellt wird. Vergleiche zunächst mit dem bestehenden Git-Ablauf. Ein Integrationsengpass muss gemessen sein, bevor er den Betrieb eines weiteren Dienstes rechtfertigt.
Der Quickstart des Projekts setzt Linux oder macOS, Git, make, das OpenSSL-Kommandozeilenprogramm, Go 1.26, eine C-Toolchain, Meson und Ninja voraus. Diese Befehle fixieren den hier geprüften Quellstand und starten anschließend dessen Beispiel. Wir haben sie im Rahmen dieses Artikels nicht ausgeführt:
git clone https://github.com/feder-cr/git-ai.git
cd git-ai
git checkout --detach 6b0ab81e6e3766824920ec18e17593fe8db714fd
make build
examples/graft/quickstart.shServer und Beispielagenten des Quickstarts demonstrieren einen Ablauf. Sie belegen weder ein Berechtigungsmodell für den Produktivbetrieb noch repräsentativen Durchsatz oder einen getesteten Wiederherstellungsplan.
| Zu prüfender Fall | Zu erhebende Nachweise |
|---|---|
| Mehrere konfliktfreie Änderungen zielen auf einen Branch | Welche Änderungen integriert werden, Wiederholungen, abgelehnte Anfragen und Latenz einschließlich erfolgloser Versuche |
| Eine Modelllösung verletzt eine Assertion zum erwarteten Verhalten | Der Kandidat bleibt ein Vorschlag und der Branch übernimmt diese Lösung nicht automatisch |
| Das Ziel verändert sich während der Verifikation | Ein veränderter Kandidat wird erneut geprüft; ein veraltetes positives Ergebnis gibt ihn nicht frei |
| Eine deterministische Regel bearbeitet einen Konflikt | Der Unterschied zwischen deaktivierter und aktivierter Verifikation ist verstanden und entspricht der vorgesehenen Regelung |
| Eine konfliktfreie Integration verletzt eine Produktregel | Die ausgewählten Prüfungen nach dem Merge erkennen den Fehler; die fehlerhafte Revision gelangt nicht in den Release-Ablauf |
| Der Verifier überspringt eine Prüfung, erreicht ein Timeout oder trifft auf einen instabilen Test | Die Release-Anbindung unterscheidet diese Ergebnisse von einem erfolgreichen Test und verhindert ein unbegründetes Zurücknehmen |
| Ein Agent fordert einen gesperrten Branch oder eine reservierte Referenz an | Berechtigungsbedingte Ablehnung, korrekte Zuordnung zum Akteur und Trennung von Betreiberrechten |
| Ein Server startet neu oder verliert seinen lokalen Repository-Cache | Wiederherstellung der erwarteten Referenz und Objekte, gemessene Wiederherstellungszeit und erhaltene Prüfnachweise |
Vergleiche die Zeit bis zur geprüften Auslieferung, Eingriffe durch Reviewer, Regressionen und die gesamten Betriebskosten. Bei autoritativem Speicherbetrieb gehören auch Speicherwachstum und Wiederherstellungszeit dazu. Legt die akzeptablen Grenzen vor dem Versuch fest, damit eine schnellere Demo nicht unbemerkt die Erfolgskriterien verschiebt.
Wavects AI Enablement kann ein Team dabei unterstützen, diese Evaluierung und die Release-Kriterien festzulegen. Unsere Hyperstate-AI-Fallstudie beschreibt andere Engineering-Arbeit, keinen gitai-Einsatz. Nutze die Software-QA-Checkliste vor dem Launch, um die Verhaltenstests abzugrenzen, oder besprich einen Integrationsengpass bei parallelen Agenten anhand aktueller Wiederholungsversuche und fehlgeschlagener Integrationen.
Häufige Fragen zur Merge-Verifikation mit gitai
Ist feder-cr/git-ai das Werkzeug zur Herkunftszuordnung von KI-Code?
Nein. feder-cr/git-ai ist ein Versionskontroll-Backend für Coding-Agenten mit einer CLI namens graft. git-ai-project/git-ai ist ein eigenständiges Projekt, das die Herkunft KI-generierten Codes erfasst. Prüfe den Repository-Inhaber, bevor du Installationsanleitungen verwendest.
Ist gitai eine offizielle Open-Source-Veröffentlichung von Anthropic Scion?
Nein. Es ist ein unabhängiges Projekt, das öffentlich beschriebene Scion-Ideen aufgreift. Anthropics interne Implementierung und gemeldete Infrastrukturergebnisse sind weder gitai-Veröffentlichungen noch Leistungszusagen für gitai.
Kann gitai einen KI-generierten Merge-Konflikt automatisch lösen?
Es unterstützt einen optionalen Resolver. Modellgenerierte Lösungen benötigen eine konfigurierte, aktivierte Verifikation, die für genau den zu integrierenden Tree erfolgreich ist. Andernfalls bleiben sie Vorschläge. Für Lösungen aus deterministischen Regeln gelten andere Standardeinstellungen.
Prüft verify.command jeden konfliktfreien Merge?
Nein. Am geprüften Commit ist der Konfliktlösungs-Verifier keine allgemeine Testschranke für konfliktfreie Integrationen. Definiere die Prüfungen für solche Änderungen gesondert und verwende Nachweise zur geprüften Revision im Release-Ablauf.
Nimmt graft-verify fehlerhafte Commits automatisch zurück?
Nur wenn Auto-Revert ausdrücklich aktiviert ist. Standardmäßig werden fehlgeschlagene Prüfungen gemeldet und die grüne Referenz bleibt an ihrer bisherigen Position. Auch ein Quellcode-Revert kann externe Auswirkungen wie eine Datenbankmigration nicht rückgängig machen.
Beweist Exit-Code null bei graft-verify eine erfolgreich geprüfte Revision?
Nein. Ein einmaliger Lauf kann erfolgreich enden, obwohl eine Gruppe von Änderungen übersprungen wurde. Prüfe das strukturierte Ergebnis und identifiziere die getestete Revision, bevor du den Lauf als Freigabenachweis verwendest.
Sollte ein kleines Team Git Worktrees durch gitai ersetzen?
Die Werkzeuge betreffen unterschiedliche Ebenen. Worktrees trennen lokale Checkouts. Evaluiere gitai, wenn gemessene Konkurrenz beim serverseitigen Landing den zusätzlichen Dienst und die Verifikationsanbindung rechtfertigt. Einige parallele Aufgaben allein belegen diesen Bedarf nicht.