Clutch Developer
DE
Gespräch buchen

Navigation

Sprache

Claude + Codex im selben Projekt mit Git-Worktrees (2026)

Gib Claude und Codex getrennte Branches in einem Repository, vereinbare die API und prüfe jede Änderung vor der Integration.

Sollen Claude und Codex an derselben App arbeiten, ohne sich Dateien zu überschreiben? Git-Worktrees geben jeder Sitzung einen eigenen Checkout und Branch. Das knüpft an meinen Leitfaden zu zwei Claude-Konten auf einem Mac an: Konten trennen Anmeldungen, Worktrees trennen Quellcode-Ordner. Das sind unterschiedliche Aufgaben.

Was ein Worktree trennt

Ein Worktree ist ein weiterer Checkout, der mit demselben Git-Repository verbunden ist. Jeder Checkout hat eigene Dateien und einen eigenen Branch, teilt aber die Commit-Historie. So können zwei Agenten unabhängig bearbeiten. Zugangsdaten, Umgebungsvariablen, Datenbanken, laufende Dienste und Deployment-Ziele werden dadurch nicht getrennt. Betrachte ihn als Arbeitsbereich für Quellcode, nicht als Sicherheitsgrenze. Ein Branch ist auch kein automatischer Release: Ein Deployment erfolgt weiterhin nur über euren regulären Ablauf.

Saubere Ausgangspunkte schaffen

Du brauchst ein Git-Repository und ein installiertes Git. Prüfe den Status und sieh dir jede Änderung an. Übernimm nur den gewünschten gemeinsamen Ausgangsstand und füge konkrete Pfade hinzu; stage nicht blind alles. Die Beispiele beginnen bei HEAD. Nicht committete Änderungen werden deshalb nicht in die neuen Checkouts übernommen.

git status --short
git worktree add -b ai/ui ../my-app-ui HEAD
git worktree add -b ai/backend ../my-app-backend HEAD

Prüfe anschließend die Worktree-Liste und beide Ordner. Git teilt die Repository-Historie, aber die Projekteinrichtung fehlt möglicherweise: Abhängigkeiten, ignorierte Dateien, Build-Caches und lokale Einstellungen brauchen in jedem Checkout Aufmerksamkeit. Verwende freigegebene Entwicklungszugänge und Testdaten; kopiere niemals automatisch Produktionsgeheimnisse. Weise gleichzeitig laufenden Servern verschiedene Ports zu und trenne bei Schreibzugriffen Testdatenbanken oder -schemas sowie Fixture-IDs. Einige lokale Prozesse oder ein Mock-Dienst reichen womöglich; du musst nicht den ganzen Stack containerisieren.

Starte das Tool im richtigen Ordner

Nutze den mit Git erstellten UI-Ordner für Claude Code und den Backend-Ordner für Codex. Öffne beide als eigenes lokales Projekt und prüfe vor der Aufgabenvergabe das Arbeitsverzeichnis. Beide Werkzeuge müssen bereits installiert und angemeldet sein.

Beide Werkzeuge bieten auch verwaltete Worktree-Abläufe (Claude, Codex). Nutze diese als Alternative zur manuellen Ordnererstellung, statt für dieselbe Aufgabe einen zweiten Worktree anzulegen.

Vor der Aufteilung den Schnittstellenvertrag festlegen

Wähle Aufgaben, die unabhängig vorankommen. Zum Beispiel übernimmt Claude den UI-Branch und baut Bildschirm samt API-Client; Codex betreut den Backend-Branch und implementiert den Endpunkt. Einigt euch vorher auf Methode und Pfad, Anfrage- und Antwortfelder, Authentifizierung, Validierungsfehler und ein Test-Fixture. Jeder Agent verantwortet genau einen Worktree; gemeinsame Dateien bekommen einen klaren Besitzer.

Zwei Agenten, unabhängige Branches, ein Review
  1. Claude · UI-Branch
  2. Vereinbarter API-Vertrag
  3. Codex · Backend-Branch
  4. Prüfen und integrieren

Getrennte Ordner schützen Dateiänderungen; der vereinbarte Payload hält beide Feature-Hälften aufeinander abgestimmt.

Ein typischer Fehler: Die Oberfläche liest items, der Endpunkt liefert aber results. Git kann diese Änderungen ohne Textkonflikt zusammenführen, obwohl das Feature kaputt ist. Vereinbart die Antwortstruktur vor paralleler Arbeit und prüft sie in beiden Implementierungen.

Prüfen, integrieren, dann aufräumen

  1. Jeden Diff prüfen. Sieh dir geänderte Dateien, Konfiguration, Migrationen und Datenzugriffe an. Führe Prüfungen für das vereinbarte Verhalten aus; eine Fertigmeldung des Agenten ist kein Nachweis.
  2. Branch für Branch integrieren. Integriere einen geprüften Branch und führe die passenden Checks aus, dann den zweiten. Wenn beide vorhanden sind, teste die Oberfläche gegen den echten Endpunkt.
  3. Verhalten prüfen, nicht nur Git. Ein konfliktfreier Merge erkennt keine abweichenden Felder, Auth-Regeln oder Annahmen über gemeinsam genutzte Dienste. Prüfe die Schnittstelle mit dem Test-Fixture.

Dafür braucht es dasselbe Urteilsvermögen wie beim Prüfen KI-generierten App-Codes oder beim Organisieren eines Programmiererteams: klare Zuständigkeiten helfen, doch das integrierte Verhalten muss ein Mensch prüfen.

Prüfe vor dem Aufräumen Status und letzte Commits jedes Checkouts und kläre, was bereits integriert ist. Liste die Worktrees auf und entferne nur den vorgesehenen, abgeschlossenen Pfad; Git soll nicht committete Arbeit schützen. Verwende weder rm -rf noch erzwungenes Entfernen als Routine.

Bei einer App vor dem Release prüft unser Code-Audit Architektur, kritisches Verhalten, Datengrenzen und Release-Nachweise im Kontext des tatsächlichen Produktumfangs.