--- title: "GitButler für KI-Agenten: Mehrere Branches, ein Build" canonical: https://wavect.io/de/blog/gitbutler-parallel-ai-agents-one-workspace/ language: de description: "GitButler für parallele KI-Agenten in einem Workspace: selektive CLI-Commits, gemeinsame Builds, Branch-Tests, Worktree-Abwägungen und Multiplayer-Grenzen." image: "https://wavect.io/img/blog/headers/header_gitbutler-parallel-ai-agents-one-workspace.png" --- [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 14 min Lesezeit · 8. Okt. 2026 Zuletzt geprüft 8. Oktober 2026 [**Weiter**](/de/blog/git-worktrees-vs-jujutsu-ai-coding-agents/) # GitButler für parallele KI-Agenten: Mehrere Branches, ein Build TL;DR Mit GitButler teilen mehrere KI-Coding-Agenten ein Arbeitsverzeichnis und einen Entwicklungsserver, während sie Aufgabenänderungen auf getrennten Branches organisieren. Wähle Änderungen beim Commit ausdrücklich aus, koordiniere gemeinsame Dateien und Operationen am gesamten Workspace und teste jeden Branch oder deklarierten Stack ebenso wie die kombinierte Anwendung. Zusammenarbeit über Remote-Branches gibt es bereits. Jederzeit synchronisierter Multiplayer-Kontext und validierter Zustand bleiben ein weitergehendes Ziel. Behandle 10x- und 100x-Behauptungen als zu prüfende Hypothesen. **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](https://docs.gitbutler.com/ai-agents/parallel-agents) 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](https://docs.gitbutler.com/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](/de/blog/atomic-multi-file-edits-ai-coding-agents/) 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](https://git-scm.com/docs/git-worktree) beschreibt mehrere Arbeitsverzeichnisse, die sich ein Repository teilen, mit jeweils eigenem Zustand wie `HEAD` und Index. | Aufgabensituation | Sinnvoller Ausgangspunkt | Was du prüfen solltest | | --- | --- | --- | | Unabhängige Features, die gemeinsam ausprobiert werden sollen | Parallele GitButler-Branches in einem Workspace | Jedes Feature funktioniert einzeln und in der kombinierten Anwendung | | Zwei Agenten untersuchen alternative Implementierungen | Getrennte Worktrees | Jede Alternative bewerten, bevor das gewählte Ergebnis integriert wird | | Ein Feature benötigt die API-Änderung eines anderen Branches | Ein ausdrücklicher Branch-Stack | Gegen die deklarierte Abhängigkeit prüfen und testen | | Unterschiedliche Abhängigkeitsversionen oder inkompatible generierte Dateien | Getrennter Checkout mit eigener Laufzeitkonfiguration | Trennung von Abhängigkeiten, Build-Ausgaben und Laufzeitumgebung | | Der Branch eines Teammitglieds soll früh auf Integration geprüft werden | In einem koordinierten gemeinsamen Workspace anwenden oder einen eigenen Review-Worktree verwenden | Die erwartete Branch-Kombination und den aktuellen Zielbranch | 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](/de/blog/git-worktrees-vs-jujutsu-ai-coding-agents/). 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](https://docs.gitbutler.com/ai-agents/getting-started). 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](https://docs.gitbutler.com/ai-agents/review-agent-work). **Ein leicht übersehener Fehler ist, die Arbeit eines anderen Agenten mit zu committen.** Laut aktueller [Referenz zu `but commit`](https://docs.gitbutler.com/commands/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](https://docs.gitbutler.com/commands/but-help-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](https://docs.gitbutler.com/cli-guides/cli-tutorial/branching-and-commiting). 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](#source-parallel). 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`](https://docs.gitbutler.com/commands/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. | Prüfziel | Frage | Aufzubewahrender Nachweis | | --- | --- | --- | | Einzelner Branch oder deklarierter Stack | Funktioniert diese Review-Einheit ausschließlich mit ihren deklarierten Abhängigkeiten? | Basis, Branch-Revisionen und Ergebnisse der relevanten Prüfungen | | Kombinierter lokaler Workspace | Funktionieren die gleichzeitig entwickelten Features gemeinsam? | Revisionen der angewendeten Branches, etwaige uncommittete Änderungen und Annahmen zur Laufzeitumgebung | | Endgültiger Integrationskandidat | Funktioniert genau dieser Kandidat gegen den aktuellen Zielbranch? | Integrationsrevision und die für diesen Kandidaten ausgeführten Prüfungen | 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](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-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`](#source-branch) 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](https://docs.gitbutler.com/commands/but-oplog) 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](https://docs.gitbutler.com/commands/but-resolve) 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](https://docs.gitbutler.com/features/branch-management/merging) 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](https://docs.gitbutler.com/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`](https://docs.gitbutler.com/commands/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](https://blog.gitbutler.com/series-a) 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](/de/blog/mosaic-yc-s26-shared-agent-sessions-review/). 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. | Bedeutung | Was geteilt werden muss | Fehler bei Verwechslung | | --- | --- | --- | | Neueste Dateien | Änderungen, Zuständigkeiten und die Branches, die in den Workspace gehören | Ein Agent überschreibt die Änderung eines anderen oder sieht eine unbeabsichtigte Branch-Kombination | | Neuester Kontext | Relevante Schnittstellenänderungen, Entscheidungen und ungültig gewordene Annahmen | Ein Agent nutzt aktuelle Dateien, argumentiert aber auf Basis einer veralteten Schnittstellenvereinbarung | | Neueste validierte Zusammenstellung | Ein festgelegter Kandidat, seine Abhängigkeiten und die dafür geltenden Prüfungen | Ein früheres erfolgreiches Testergebnis gilt fälschlich als Freigabe für einen anderen Zustand | 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](/de/services/ai-enablement/) kann Teams helfen, diese Arbeitsregeln zu definieren und anhand der tatsächlich ausgelieferten Änderungen zu bewerten. Unsere [Engineering-Fallstudie zu Hyperstate AI](/de/case-studies/hyperstate-ai/) ist ein eigenständiges Produktprojekt. Sie belegt weder einen GitButler-Einsatz noch einen Geschwindigkeitsbenchmark. Nutze die [Software-QA-Checkliste vor dem Launch](/de/software-development-guide/software-qa-checklist-before-launch/), um Abnahmekriterien konkret zu machen, oder [besprich den Entwicklungsworkflow deines Teams mit parallelen Agenten](/de/contact/). Bringe zwei repräsentative Aufgaben, einen kürzlich aufgetretenen Integrationsfehler und euren heutigen Review-Prozess mit. ## GitButler und parallele KI-Agenten: Häufige Fragen ### Können mehrere KI-Agenten GitButler im selben Arbeitsverzeichnis verwenden? Ja. GitButler dokumentiert parallele Agentensitzungen, die einen Workspace teilen und aufgabenspezifische Änderungen auf getrennte Branches committen. Dateien, generierte Ausgaben und Laufzeitzustand bleiben gemeinsam. Überschneidende Arbeit braucht deshalb Koordination. ### Muss ich die GitButler-Desktop-App verwenden? Der dokumentierte Agenten-Workflow verwendet die but-CLI. Nach deren Installation kann but agent setup den Skill installieren und Repository-Anweisungen konfigurieren. Menschen können die Arbeit über CLI, TUI oder Desktop-App prüfen. ### Ersetzt GitButler Git Worktrees für KI-Agenten? Es bietet eine Alternative mit gemeinsamem Workspace. Nutze parallele Branches für kompatible Aufgaben, die du gemeinsam ausführen möchtest. Nutze getrennte Worktrees für inkompatible Checkouts, konkurrierende Implementierungen oder getrennt konfigurierte Laufzeitumgebungen. ### Beweist ein erfolgreicher gemeinsamer Build, dass jeder Branch auslieferbar ist? Nein. Ein Branch kann von einem anderen angewendeten Branch abhängen, der bei seiner Auslieferung fehlt. Prüfe jede Review-Einheit gegen ihre deklarierte Basis und ihre Abhängigkeiten, außerdem den kombinierten Workspace und den endgültigen Integrationskandidaten. ### Verhindert GitButler, dass Agenten gegenseitig Änderungen überschreiben? Behandle eine Branch-Zuordnung nicht als Dateisperre. Agenten teilen ein Dateisystem. Koordiniere überschneidende Änderungen und Operationen am gesamten Workspace, aktualisiere veraltete Lesestände und prüfe vor dem Commit den ausgewählten Diff. ### Ist jederzeit synchronisiertes Multiplayer-GitButler verfügbar? Die am 8. Oktober 2026 geprüfte Dokumentation unterstützt Zusammenarbeit über Remote-Branches und lokale parallele Arbeit. Sie belegt keine allgemeine Live-Synchronisierung sämtlicher uncommitteter Dateien, Agentenkontexte und validierter Laufzeitzustände aller Beteiligten. ### Macht GitButler die Entwicklung zehnmal schneller? Dieser Artikel belegt keinen 10x-Benchmark. Persönliche Beschleunigungsberichte und 100x-Prognosen für Multiplayer sollten anhand vergleichbarer Aufgaben, Zeit bis zu getesteten Änderungen, Review-Aufwand, Nacharbeit und Gesamtkosten pro akzeptierter Änderung bewertet werden. ## Fazit GitButler ermöglicht einen überzeugenden Workflow: mehrere Agenten, separat prüfbare Branches und eine Anwendung, die ihre kompatiblen Änderungen gemeinsam zeigt. Gib Agenten klare Zuständigkeiten, committe gezielt ausgewählte Änderungen und prüfe die tatsächliche Einheit, die du ausliefern möchtest. Der nächste Multiplayer-Fortschritt wird davon abhängen, neben aktuellen Dateien auch aktuelle Entscheidungen und validierte Zusammenstellungen zu teilen. Architektur und Plattformen ## In diesem Cluster weiterlesen Framework-, Plattform- und Systementscheidungen mit langfristiger Delivery-Wirkung. [Mit dem Grundlagenartikel starten**Smart-City-Architektur: MQTT, LoRaWAN, Kubernetes und Terraform**](/de/blog/smart-city-architecture-best-practices-2026/) - [KI-Code und Wettbewerbsvorteile: Wer betreibt die Software?](/de/blog/ai-coding-software-moat-operations/) - [Shopify-B2B-Bestellfreigaben: native Funktionen, Apps oder individuelles Kundenportal?](/de/blog/shopify-b2b-order-approval-workflow/) - [Shopify–ERP: Retouren und Erstattungen, wenn der Standard-Connector nicht genügt](/de/blog/shopify-erp-returns-refunds-integration/) - [ERP ohne API anbinden: Dateiaustausch, Datenbankzugriff, RPA oder Ablösung?](/de/blog/legacy-erp-integration-without-api/) - [Mehrere Shopify-Shops verwalten: Reporting-App oder individuelles Operations-Dashboard?](/de/blog/shopify-multi-store-operations-dashboard/) [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 14 min Lesezeit · 8. Okt. 2026 Zuletzt geprüft 8. Oktober 2026 [**Weiter**](/de/blog/git-worktrees-vs-jujutsu-ai-coding-agents/) ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/gitbutler-parallel-ai-agents-one-workspace/#webpage", "@type": "WebPage", "dateModified": "2026-10-08", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-10-08", "url": "https://wavect.io/de/blog/gitbutler-parallel-ai-agents-one-workspace/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Mit GitButler teilen mehrere KI-Coding-Agenten ein Arbeitsverzeichnis und einen Entwicklungsserver, während sie Aufgabenänderungen auf getrennten Branches organisieren. Wähle Änderungen beim Commit ausdrücklich aus, koordiniere gemeinsame Dateien und Operationen am gesamten Workspace und teste jeden Branch oder deklarierten Stack ebenso wie die kombinierte Anwendung. Zusammenarbeit über Remote-Branches gibt es bereits. Jederzeit synchronisierter Multiplayer-Kontext und validierter Zustand bleiben ein weitergehendes Ziel. Behandle 10x- und 100x-Behauptungen als zu prüfende Hypothesen.", "articleBody": " Blog-Übersicht/Delivery und QA/Architektur und Plattformen GitButler für parallele KI-Agenten: Mehrere Branches, ein Build TL;DR Mit GitButler teilen mehrere KI-Coding-Agenten ein Arbeitsverzeichnis und einen Entwicklungsserver, während sie Aufgabenänderungen auf getrennten Branches organisieren. Wähle Änderungen beim Commit ausdrücklich aus, koordiniere gemeinsame Dateien und Operationen am gesamten Workspace und teste jeden Branch oder deklarierten Stack ebenso wie die kombinierte Anwendung. Zusammenarbeit über Remote-Branches gibt es bereits. Jederzeit synchronisierter Multiplayer-Kontext und validierter Zustand bleiben ein weitergehendes Ziel. Behandle 10x- und 100x-Behauptungen als zu prüfende Hypothesen. 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. Entscheide danach, wie sich die Aufgaben gegenseitig beeinflussen AufgabensituationSinnvoller AusgangspunktWas du prüfen solltest Unabhängige Features, die gemeinsam ausprobiert werden sollenParallele GitButler-Branches in einem WorkspaceJedes Feature funktioniert einzeln und in der kombinierten Anwendung Zwei Agenten untersuchen alternative ImplementierungenGetrennte WorktreesJede Alternative bewerten, bevor das gewählte Ergebnis integriert wird Ein Feature benötigt die API-Änderung eines anderen BranchesEin ausdrücklicher Branch-StackGegen die deklarierte Abhängigkeit prüfen und testen Unterschiedliche Abhängigkeitsversionen oder inkompatible generierte DateienGetrennter Checkout mit eigener LaufzeitkonfigurationTrennung von Abhängigkeiten, Build-Ausgaben und Laufzeitumgebung Der Branch eines Teammitglieds soll früh auf Integration geprüft werdenIn einem koordinierten gemeinsamen Workspace anwenden oder einen eigenen", "articleSection": "KI-Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "Dokumentation zu parallelen Agenten", "url": "https://docs.gitbutler.com/ai-agents/parallel-agents" }, { "@type": "WebPage", "name": "Dokumentation zum Workspace-Branch", "url": "https://docs.gitbutler.com/workspace-branch" }, { "@type": "WebPage", "name": "Git-Worktree-Dokumentation", "url": "https://git-scm.com/docs/git-worktree" }, { "@type": "WebPage", "name": "Einrichtungsleitfaden für Agenten", "url": "https://docs.gitbutler.com/ai-agents/getting-started" }, { "@type": "WebPage", "name": "Workflow zum Review von Agentenarbeit", "url": "https://docs.gitbutler.com/ai-agents/review-agent-work" }, { "@type": "WebPage", "name": "Referenz zu but commit", "url": "https://docs.gitbutler.com/commands/but-commit" }, { "@type": "WebPage", "name": "Dokumentation zu CLI-IDs", "url": "https://docs.gitbutler.com/commands/but-help-cli-ids" }, { "@type": "WebPage", "name": "Tutorial zu Branches und Commits", "url": "https://docs.gitbutler.com/cli-guides/cli-tutorial/branching-and-commiting" }, { "@type": "WebPage", "name": "Referenz zu but branch", "url": "https://docs.gitbutler.com/commands/but-branch" }, { "@type": "WebPage", "name": "Dokumentation zur Merge Queue", "url": "https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue" }, { "@type": "WebPage", "name": "Referenz zum Operationsprotokoll", "url": "https://docs.gitbutler.com/commands/but-oplog" }, { "@type": "WebPage", "name": "CLI zur Konfliktlösung", "url": "https://docs.gitbutler.com/commands/but-resolve" }, { "@type": "WebPage", "name": "Leitfaden zu Rebase und Konflikten", "url": "https://docs.gitbutler.com/features/branch-management/merging" }, { "@type": "WebPage", "name": "Butler Flow", "url": "https://docs.gitbutler.com/butler-flow" }, { "@type": "WebPage", "name": "Referenz zu but pull", "url": "https://docs.gitbutler.com/commands/but-pull" }, { "@type": "WebPage", "name": "Series-A-Ankündigung", "url": "https://blog.gitbutler.com/series-a" } ], "dateModified": "2026-10-08", "datePublished": "2026-10-08", "description": "Mit GitButler teilen mehrere KI-Coding-Agenten ein Arbeitsverzeichnis und einen Entwicklungsserver, während sie Aufgabenänderungen auf getrennten Branches organisieren. Wähle Änderungen beim Commit ausdrücklich aus, koordiniere gemeinsame Dateien und Operationen am gesamten Workspace und teste jeden Branch oder deklarierten Stack ebenso wie die kombinierte Anwendung. Zusammenarbeit über Remote-Branches gibt es bereits. Jederzeit synchronisierter Multiplayer-Kontext und validierter Zustand bleiben ein weitergehendes Ziel. Behandle 10x- und 100x-Behauptungen als zu prüfende Hypothesen.", "headline": "GitButler für parallele KI-Agenten: Mehrere Branches, ein Build", "image": "https://wavect.io/img/blog/headers/header_gitbutler-parallel-ai-agents-one-workspace.svg", "inLanguage": "de", "keywords": "GitButler, Parallele KI-Agenten, KI-Coding-Agenten, Git Worktrees, Entwickler-Workflows", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/gitbutler-parallel-ai-agents-one-workspace/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/gitbutler-parallel-ai-agents-one-workspace/", "wordCount": 2934 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/delivery-qa/", "name": "Delivery und QA", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/architecture-platforms/", "name": "Architektur und Plattformen", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/gitbutler-parallel-ai-agents-one-workspace/", "name": "GitButler für KI-Agenten: Mehrere Branches, ein Build", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Ja. GitButler dokumentiert parallele Agentensitzungen, die einen Workspace teilen und aufgabenspezifische Änderungen auf getrennte Branches committen. Dateien, generierte Ausgaben und Laufzeitzustand bleiben gemeinsam. Überschneidende Arbeit braucht deshalb Koordination." }, "name": "Können mehrere KI-Agenten GitButler im selben Arbeitsverzeichnis verwenden?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Der dokumentierte Agenten-Workflow verwendet die but-CLI. Nach deren Installation kann but agent setup den Skill installieren und Repository-Anweisungen konfigurieren. Menschen können die Arbeit über CLI, TUI oder Desktop-App prüfen." }, "name": "Muss ich die GitButler-Desktop-App verwenden?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Es bietet eine Alternative mit gemeinsamem Workspace. Nutze parallele Branches für kompatible Aufgaben, die du gemeinsam ausführen möchtest. Nutze getrennte Worktrees für inkompatible Checkouts, konkurrierende Implementierungen oder getrennt konfigurierte Laufzeitumgebungen." }, "name": "Ersetzt GitButler Git Worktrees für KI-Agenten?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nein. Ein Branch kann von einem anderen angewendeten Branch abhängen, der bei seiner Auslieferung fehlt. Prüfe jede Review-Einheit gegen ihre deklarierte Basis und ihre Abhängigkeiten, außerdem den kombinierten Workspace und den endgültigen Integrationskandidaten." }, "name": "Beweist ein erfolgreicher gemeinsamer Build, dass jeder Branch auslieferbar ist?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Behandle eine Branch-Zuordnung nicht als Dateisperre. Agenten teilen ein Dateisystem. Koordiniere überschneidende Änderungen und Operationen am gesamten Workspace, aktualisiere veraltete Lesestände und prüfe vor dem Commit den ausgewählten Diff." }, "name": "Verhindert GitButler, dass Agenten gegenseitig Änderungen überschreiben?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Die am 8. Oktober 2026 geprüfte Dokumentation unterstützt Zusammenarbeit über Remote-Branches und lokale parallele Arbeit. Sie belegt keine allgemeine Live-Synchronisierung sämtlicher uncommitteter Dateien, Agentenkontexte und validierter Laufzeitzustände aller Beteiligten." }, "name": "Ist jederzeit synchronisiertes Multiplayer-GitButler verfügbar?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Dieser Artikel belegt keinen 10x-Benchmark. Persönliche Beschleunigungsberichte und 100x-Prognosen für Multiplayer sollten anhand vergleichbarer Aufgaben, Zeit bis zu getesteten Änderungen, Review-Aufwand, Nacharbeit und Gesamtkosten pro akzeptierter Änderung bewertet werden." }, "name": "Macht GitButler die Entwicklung zehnmal schneller?" } ] } ```