GitButler für parallele KI-Agenten: Mehrere Branches, ein Build

Mit GitButler können parallele KI-Coding-Agenten getrennte Branches in einem gemeinsamen Arbeitsverzeichnis zusammenführen. Kompatible Änderungen laufen dadurch gemeinsam in einer lokalen Anwendung. Die Dokumentation zu parallelen Agenten beschreibt ausdrücklich, wie Agenten eine Abhängigkeitsinstallation und einen Entwicklungsserver teilen, während sie die Änderungen jeder Aufgabe separat committen.

Der Nutzen ist unmittelbar nachvollziehbar: Ein Feature, ein unabhängiger Fix und die Aufgabe eines weiteren Agenten kommen voran, während du ihr gemeinsames Ergebnis prüfst. Ein Agent kann die Versionskontrolloperationen über die CLI übernehmen. Der Entwickler steuert die Arbeit und beurteilt das Produkt.

Der nächste Entwicklungsschritt ist Multiplayer-Entwicklung: Mehrere Menschen und Agenten koordinieren sich rund um ein laufend aktualisiertes Produkt. Die Herausforderung liegt darin, sich darüber einig zu sein, was „aktualisiert“ bedeutet. Aktuelle Dateien, aktuelles Agentenwissen und eine geprüfte Integration sind drei unterschiedliche Zustände.

Quellen geprüft am 8. Oktober 2026. Die folgenden Befehle entsprechen der aktuellen offiziellen Dokumentation und dienen als Beispiele. Sie sind kein Protokoll einer durchgeführten GitButler-Ausführung. Die vorgeschlagenen Arbeitsregeln und die Prüfmatrix sind Wavects Analyse. „10x“-Beschleunigungen und „100x“-Gewinne durch Multiplayer behandeln wir als Erfahrungsbehauptungen und Prognosen, nicht als gemessene Wavect-Ergebnisse.

Wie bringt GitButler mehrere Branches in einen laufenden Build?

GitButler kombiniert angewendete Branches in einem gemeinsamen Checkout und erhält dabei ihre getrennten Historien. Die Dokumentation zum Workspace-Branch erklärt den erzeugten Merge-Commit gitbutler/workspace und den kombinierten, committeten Zustand, den gewöhnliche Git-Werkzeuge sehen.

Dadurch erhält nicht jeder Agent ein eigenes Dateisystem. Alle sehen dieselben Dateien, dieselbe Abhängigkeitsinstallation und dieselben generierten Ausgaben. Das ist hilfreich, wenn ein Kundenfilter und ein unabhängiger Fix für die Rechnungsanzeige nebeneinander bestehen können. Es wird zur Koordinationsaufgabe, wenn beide Agenten denselben gemeinsamen Typ umschreiben oder dasselbe Artefakt generieren.

„Ein laufender Build“ bedeutet, dass der Entwicklungsprozess die kombinierten Dateien verwenden kann. Es garantiert weder atomare Dateiaktualisierungen noch, dass Hot Reload jede Änderung verarbeitet oder Abhängigkeiten und Datenbankzustand nie einen Neustart erfordern. Unser Leitfaden zu atomaren Änderungen mehrerer Dateien durch Coding-Agenten erklärt, welchen Zustand ein laufender Leseprozess während solcher Änderungen beobachten kann.

Nutze im verwalteten Workspace die Schreiboperationen von GitButler. Wer gitbutler/workspace wie einen gewöhnlichen Feature-Branch behandelt und direkt darauf committet, arbeitet gegen die vom Tool verwaltete Struktur.

Wann sollten KI-Agenten GitButler gemeinsam nutzen und wann Worktrees?

Teile einen Workspace, wenn die Aufgaben Dateien und Laufzeitzustand teilen können. Nutze getrennte Worktrees, wenn sie inkompatible Checkouts oder konkurrierende Implementierungen benötigen. Die offizielle Git-Worktree-Dokumentation beschreibt mehrere Arbeitsverzeichnisse, die sich ein Repository teilen, mit jeweils eigenem Zustand wie HEAD und Index.

Ein Worktree trennt die ausgecheckten Dateien. Richte getrennte Ports, Datenbanken und externe Ressourcen ein, wenn die Aufgaben auch dort Isolation benötigen. Umgekehrt beweisen zwei Dateien in unterschiedlichen Ordnern noch keine Unabhängigkeit ihrer Änderungen. Ein gemeinsames Schema, eine Lockdatei oder eine Migration kann sie verbinden.

Die umfassendere Entscheidung zu Repository und Bereitstellung behandelt unser Vergleich von Git Worktrees und Jujutsu für KI-Coding-Agenten. Hier geht es um die engere Frage: Möchtest du eine gemeinsam zusammengesetzte lokale Anwendung oder physisch getrennte Arbeitsstände?

Kann ein Agent GitButler ohne Desktop-App steuern?

Ja. GitButler dokumentiert einen Agenten-Workflow über die but-CLI. Beginne mit dem Einrichtungsleitfaden für Agenten. Führe nach der CLI-Installation diese Befehle im Repository aus:

but agent setup
but status

Der Einrichtungsassistent kann den Skill installieren, Workflow-Anweisungen schreiben und bei Bedarf den Workspace-Modus initialisieren. Prüfe den vorgeschlagenen Umfang und die Änderungen an den Anweisungen. Der Skill vermittelt dem Agenten die Bedienung von GitButler. Repository-Berechtigungen und Schutzregeln für Branches setzen die Zugriffsgrenzen.

Anschließend kannst du ein Ergebnis in gewöhnlicher Sprache beschreiben, zum Beispiel:

Implementiere den Kundenfilter auf feature/customer-filter. Halte unabhängige Fixes getrennt. Stimme Änderungen an gemeinsam genutzten Dateien mit dem anderen Agenten ab. Committe nur die Änderungen dieser Aufgabe und nenne die Branch-Basis sowie die ausgeführten Prüfungen.

Das ist ein vorgeschlagener Arbeitsauftrag, kein besonderer Befehl. Der Agent soll ihn in die passenden Operationen übersetzen. Für die menschliche Prüfung unterstützt GitButler CLI-, TUI- und Desktop-Ansichten über seinen Workflow zum Review von Agentenarbeit.

Ein leicht übersehener Fehler ist, die Arbeit eines anderen Agenten mit zu committen. Laut aktueller Referenz zu but commit umfasst der Befehl standardmäßig alle noch nicht committeten Änderungen. Die Angabe eines Zielbranches allein beschränkt die Auswahl nicht auf die Änderungen dieser Aufgabe. Wähle die vorgesehenen Dateien oder Änderungsblöcke über ihre Änderungs-IDs als Positionsargumente aus.

Die folgenden IDs sind Beispiele. Ersetze q3, w7 und n2 durch IDs aus deiner eigenen aktuellen Ausgabe und prüfe jede Auswahl, bevor du fortfährst. GitButlers Dokumentation zu CLI-IDs warnt davor, dass sich Kennungen mit dem Workspace-Kontext ändern können.

but diff
but commit -b feature/customer-filter -m "Add customer filter" q3 w7

but diff
but commit -b fix/invoice-display -m "Fix invoice display" n2

but status

Das entspricht dem Vorgehen für selektive Commits im Tutorial zu Branches und Commits. Existiert der benannte Zielbranch noch nicht, legt -b ihn als parallelen Branch an. Existiert er bereits, ist aber nicht angewendet, lehnt der Commit-Befehl dieses Ziel ab. Stimme Auswahl und Schreiboperation so ab, dass ein anderer schreibender Prozess die gerade geprüfte Auswahl nicht ungültig macht.

Wie vermeiden mehrere Agenten, Änderungen gegenseitig zu überschreiben oder zu vermischen?

Die Branch-Zuordnung braucht klare Zuständigkeiten für gemeinsam genutzte Dateien. Weise jeder Aufgabe einen Branch und einen abgegrenzten Arbeitsbereich zu. Benenne typische Kollisionsstellen vorab: Routing-Tabellen, gemeinsame Typen, Abhängigkeitsmanifeste, Lockdateien, Migrationen und generierten Code.

Angenommen, zwei Agenten lesen dieselbe Datei, bevor einer sie bearbeitet. Überschreibt der zweite Agent später die gesamte Datei auf Basis seines veralteten Stands, kann er die Änderung des ersten entfernen, bevor zwei gespeicherte Commits zum Zusammenführen vorliegen. Eine Branch-Zuordnung macht diesen Dateisystemzugriff nicht exklusiv.

Unser Vorschlag: Unabhängige Implementierungsarbeit bleibt parallel. Ein koordinierender Agent oder Entwickler übernimmt die Abstimmung von Operationen, die den gesamten gemeinsamen Workspace verändern. Dazu gehören das Anwenden oder Entfernen von Branches, das Aktualisieren des Zielbranches, das Umordnen der Historie und der Wechsel in einen Konfliktlösungsmodus. Agenten können diese Koordination übernehmen. Nicht jede Routineentscheidung muss an einen Menschen zurückgehen.

Lies vor dem Bearbeiten einer gemeinsam genutzten Datei den relevanten Inhalt erneut und kläre, wer die Änderung verantwortet. Prüfe vor dem Commit den tatsächlich ausgewählten Diff. Ändert ein anderer Agent eine Schnittstelle, von der deine Aufgabe abhängt, aktualisiere deine Annahmen und wiederhole die betroffenen Prüfungen. Das sind Workflow-Empfehlungen. Sie behaupten weder, dass GitButler Dateizuständigkeiten erzwingt, noch, dass es den Kontext jedes Agenten automatisch aktualisiert.

Warum kann ein erfolgreicher gemeinsamer Build einen kaputten Branch verbergen?

Ein erfolgreicher kombinierter Build bestätigt die geprüfte Zusammenstellung. Er belegt nicht, dass jeder Branch unabhängig funktioniert. Das ist die praktische Folge des dokumentierten Risikos versteckter Abhängigkeiten.

In einem hypothetischen Beispiel ergänzt Branch A eine Lieferprognose in einer API-Antwort. Branch B fügt ein Badge hinzu, das dieses Feld ausliest. Sind beide Branches angewendet, funktioniert das Feature. Wird B gegen einen Zielbranch ohne A geprüft und ausgeliefert, kann das Badge fehlschlagen, obwohl sich keine Codezeilen widersprechen.

Ist diese Abhängigkeit beabsichtigt, mache sie ausdrücklich sichtbar. Die aktuelle Referenz zu but branch dokumentiert das Erstellen eines abhängigen Branches mit but branch new delivery-badge --above delivery-api. Sollte B unabhängig sein, entferne die unbeabsichtigte Abhängigkeit oder ändere den Auslieferungsplan.

Führe isolierte Branch- oder Stack-Prüfungen in einem geeigneten Checkout oder einer CI-Umgebung aus. Branches laufend aus einem Workspace zu entfernen, in dem andere Agenten arbeiten, kann neue Störungen verursachen.

GitHubs Dokumentation zur Merge Queue verdeutlicht die letzte Unterscheidung: Erforderliche Prüfungen laufen gegen eine Integration aus aktuellem Zielbranch und den Änderungen in der Warteschlange. Eine Queue führt konfigurierte Prüfungen aus. Sie beweist kein Verhalten, das diese Prüfungen nicht untersuchen.

Halte genau fest, was getestet wurde. Bearbeiten Agenten während eines Testlaufs weiter Dateien, kann sich das Ergebnis auf eine Mischung verschiedener Zustände beziehen. Nutze für eine Freigabeentscheidung einen stabilen Kandidaten und prüfe erneut, wenn sich relevante Eingaben ändern. Die gemeinsame Vorschau bleibt für schnelles Feedback wertvoll, während die Review-Nachweise an einen reproduzierbaren Stand gebunden bleiben.

Was passiert, wenn das Review eines fremden Branches Konflikte auslöst?

Unterscheide zuerst die Zusammenführbarkeit mit dem Zielbranch von der Kompatibilität mit dem aktuellen Workspace. Die von but branch list und but branch show BRANCH --check beschriebenen Prüfungen betreffen den Upstream-Zielbranch. Ein Branch, der dazu passt, kann dennoch mit anderen lokal angewendeten Änderungen kollidieren.

Stimme vor einem Review, das den Arbeitsstand verändert, die Branch-Kombination ab und sichere einen Wiederherstellungspunkt. Die Referenz zum Operationsprotokoll dokumentiert but oplog snapshot -m "Before branch review". Sichere bei Bedarf den Anwendungszustand separat. Ein Wiederherstellungspunkt in der Versionskontrolle ist kein Datenbank-Backup.

Die CLI zur Konfliktlösung unterstützt einen KI-gestützten Weg über --ai. Außerdem dokumentiert sie but resolve conflicts und but resolve apply, um konfliktbehaftete Commits zu bearbeiten, ohne in den Lösungsmodus zu wechseln.

Der klassische interaktive Weg wirkt anders. Der Leitfaden zu Rebase und Konflikten beschreibt, wie der kombinierte Checkout vorübergehend durch den konfliktbehafteten Commit ersetzt wird. Stimme diese Änderung mit anderen schreibenden Prozessen und der laufenden Anwendung ab. Gehe nicht davon aus, dass sich alle Lösungswege gleich auf den Workspace auswirken.

Ein Agent kann einen einfachen Textkonflikt schnell auflösen. Ein Bericht über „unter einer Minute“ belegt jedoch nicht, dass das Ergebnis die Absicht beider Aufgaben erhält. Prüfe geänderte Schnittstellen, Verhalten und generierte Artefakte. Führe anschließend die relevanten Einzel- und Integrationsprüfungen aus. Zeit für Konfliktlösung und Zeit für Verifikation sind getrennte Teile des Workflows.

Ist ein Multiplayer-Workflow mit GitButler bereits verfügbar?

GitButler unterstützt bereits Zusammenarbeit über Remote-Branches. Die geprüfte Dokumentation belegt keinen jederzeit synchronisierten Workspace für die uncommittete Arbeit aller Beteiligten. Butler Flow erklärt, wie Remote-Branches von Teammitgliedern neben der eigenen lokalen Arbeit angewendet werden, um die Integration früh zu prüfen. Das umfasst auch Branches, die ohne GitButler erstellt wurden.

Die Referenz zu but pull dokumentiert eine ausdrückliche Aktualisierung: Remote-Änderungen abrufen und alle angewendeten Branches auf den aktualisierten Zielbranch rebasen. but pull --check zeigt eine Vorschau der Aktualisierung. Stimme sie mit aktiven Agenten ab, da sie deren gemeinsamen Arbeitsstand verändern kann.

Die Multiplayer-Richtung ist glaubwürdig. In seiner Series-A-Ankündigung beschreibt GitButler eine Zukunft, in der Teams Konflikte früher erkennen, auf laufend veränderten Branches aufbauen und Agenten die Aktivitäten des Teams verstehen. Das ist eine öffentliche Produktvision. Sie ist keine Release-Zusage für jedes Synchronisationsverhalten, das ein Team benötigen könnte.

Wir erwarten den nächsten wesentlichen Fortschritt dort, wo zwischen einer hilfreichen Änderung eines Teammitglieds und der informierten Reaktion aller anderen weniger Zeit vergeht. Code zu teilen ist ein Teil davon. Ebenso nötig ist es, zu teilen, welche Version geprüft wurde, was noch vorläufig ist und warum eine Entscheidung getroffen wurde.

Zusammenarbeit über gemeinsame Sitzungen und Organisationskontext behandelt unsere Analyse gemeinsamer Agentensitzungen mit Mosaic. Synchronisierte Gespräche und ein synchronisierter Produktzustand beantworten unterschiedliche Fragen.

Was würde „alle sind auf dem neuesten Stand“ tatsächlich erfordern?

Ein nützliches Multiplayer-System muss aktuelle Dateien, aktuellen Agentenkontext und eine aktuell validierte Zusammenstellung unterscheiden. Das ist unser Vorschlag zur Bewertung der Idee, keine Beschreibung einer bestehenden GitButler-Funktion.

Automatische Synchronisierung sollte es weiterhin ermöglichen, einen stabilen Review-Kandidaten festzuhalten, während die Entwicklung an anderer Stelle weitergeht. Ein Reviewer muss wissen, welche Revision er freigegeben hat. Ein Entwickler, der einen Fehler untersucht, muss ihn reproduzieren können. Ein Teammitglied sollte einen vorläufigen Branch ablehnen können, ohne den Zugriff auf bereits akzeptierte Arbeit zu verlieren.

Auch Abhängigkeiten müssen mit der Änderung weitergegeben werden. Benötigt ein UI-Branch einen API-Branch, sollte das Team diese Beziehung sehen, bevor es einen der beiden isoliert freigibt. Ändert ein anderes Teammitglied die API, brauchen betroffene Agenten einen konkreten Anlass, sie erneut zu lesen. Eine bloße Benachrichtigung über geänderte Dateien reicht dafür nicht.

Darin liegt die inhaltliche „100x“-Ambition: Koordinationsverzögerungen im gesamten Team reduzieren und dabei verständliche, testbare Änderungen erhalten. Der Faktor und der Zeitpunkt bleiben Prognosen. Mehr gleichzeitige Änderungen allein können diese Verbesserung nicht belegen.

Wie sollte ein Team die behauptete Entwicklungsgeschwindigkeit prüfen?

Miss akzeptierte Arbeit und Koordinationsaufwand. Beginne mit einem kleinen, repräsentativen Aufgabenpaar. Probiere ein Feature und einen unabhängigen Fix aus. Prüfe jede Review-Einheit, führe beide gemeinsam aus und integriere sie gegen den aktuellen Zielbranch. Wiederhole den Vergleich mit dem bisherigen Team-Workflow und mit getrennten Worktrees, sofern diese eine plausible Alternative sind.

Nutze vergleichbare Aufgaben und dokumentiere ihre Komplexität, die Agenten- und Modellkonfiguration sowie die Verfügbarkeit der Reviewer. Erfasse die verstrichene Zeit bis zu einer prüfbaren, getesteten Änderung, Reviewer-Minuten pro akzeptierter Änderung, Nacharbeit bei der Integration und Fehler, die erst beim isolierten Test eines Branches auffallen. Zähle auch die Modell- und Infrastrukturkosten für Wiederholungen und Korrekturen mit.

Ein persönlicher „10x“-Erfahrungsbericht kann ein sinnvoller Anlass für ein Experiment sein. Er legt das Ergebnis eines anderen Teams nicht fest. Die Verbesserung kann aus weniger Einrichtungsschritten, weniger Kontextwechseln, schnellerem gemeinsamen Feedback oder weniger manueller Versionskontrollarbeit stammen. Ermittle, was sich tatsächlich verändert hat, bevor du den gesamten Gewinn einem einzigen Tool zuschreibst.

Wavects AI Enablement kann Teams helfen, diese Arbeitsregeln zu definieren und anhand der tatsächlich ausgelieferten Änderungen zu bewerten. Unsere Engineering-Fallstudie zu Hyperstate AI ist ein eigenständiges Produktprojekt. Sie belegt weder einen GitButler-Einsatz noch einen Geschwindigkeitsbenchmark.

Nutze die Software-QA-Checkliste vor dem Launch, um Abnahmekriterien konkret zu machen, oder besprich den Entwicklungsworkflow deines Teams mit parallelen Agenten. Bringe zwei repräsentative Aufgaben, einen kürzlich aufgetretenen Integrationsfehler und euren heutigen Review-Prozess mit.