Git-Workflow mit Worktrees

Die Lösung ist nicht ein zweites GitHub-Repository, sondern ein zweiter lokaler Arbeitsordner mit einem eigenen Branch. Git bleibt die gemeinsame Übergabeschicht.

Das Problem mit einem gemeinsamen Ordner

Mein bestehender Projektordner liegt lokal unter C:\Users\user0\Desktop\Projekte\newwaves.dev. Dort arbeitet Codex bisher direkt am Branch main. Claude Code könnte theoretisch denselben Ordner öffnen, aber das wäre unnötig riskant.

Wenn zwei Apps gleichzeitig dieselben Dateien beobachten, formatieren oder bearbeiten, ist schnell unklar, wer welchen Zwischenstand geschrieben hat. Besonders kritisch sind zentrale Dateien wie assets/css/style.css, weil fast das gesamte Design meiner statischen Website dort liegt.

• Beide Tools könnten dieselbe Datei gleichzeitig ändern.
• Ein Dev-Server oder Watcher könnte Zwischenstände sehen.
• Unfertige Änderungen wären schwerer auseinanderzuhalten.
• Konflikte würden im Arbeitsordner entstehen, nicht kontrolliert beim Merge.

Branch und Worktree

Der wichtigste Lernmoment für mich war die Trennung zwischen Branch und Worktree. Ein Branch ist die Entwicklungslinie. Ein Worktree ist der lokale Ordner, der einen Branch ausgecheckt hat.

Branch   = Version / Entwicklungslinie
Worktree = lokaler Ordner, der einen Branch zeigt

Mein bestehender Ordner bleibt deshalb einfach so, wie er ist. Er muss nicht in newwaves.dev-codex umbenannt werden und er muss auch nicht zwingend auf einen Branch namens codex wechseln.

Meine lokale Git-Architektur

Lokal gibt es jetzt zwei Arbeitsordner. Beide gehören zum selben Git-Projekt, aber sie zeigen unterschiedliche Branches.

C:\Users\user0\Desktop\Projekte
├─ newwaves.dev
│  └─ Branch: main
│     Kommentar: bestehender Hauptordner, weiter für Codex und stabile Arbeit
│
└─ newwaves.dev-claude
   └─ Branch: claude
      Kommentar: eigener Arbeitsordner für Claude Code

Auf GitHub bleibt es trotzdem ein einziges Repository. Nur die Branches können dort sichtbar werden, wenn ich sie pushe.

GitHub
└─ new-waves/newwaves.dev
   ├─ main      # stabiler Hauptstand
   └─ claude    # Claude-Branch, falls gepusht

VPS
└─ /var/www/newwaves.dev
   └─ main      # Live-Website

Der VPS bleibt dadurch einfach. Er bekommt nicht alle Experimente, sondern zieht am Ende den fertigen Stand von main.

Den Claude-Worktree anlegen

Nachdem der lokale main sauber war, habe ich den zweiten Arbeitsordner direkt neben dem bestehenden Projektordner angelegt:

cd C:\Users\user0\Desktop\Projekte\newwaves.dev
git worktree add ..\newwaves.dev-claude -b claude

Dieser Befehl macht zwei Dinge gleichzeitig: Er erstellt den Branch claude und legt den Ordner newwaves.dev-claude als Worktree an.

git worktree list

C:/Users/user0/Desktop/Projekte/newwaves.dev        c7aa491 [main]
C:/Users/user0/Desktop/Projekte/newwaves.dev-claude c7aa491 [claude]

Danach kann Claude Code den Ordner C:\Users\user0\Desktop\Projekte\newwaves.dev-claude als Projektordner bekommen.

Vorbereitung der CSS-Datei

Bevor Claude Code loslegt, habe ich assets/css/style.css in klare Abschnitte gegliedert. Dabei wurden nur Kommentare eingefügt, keine CSS-Regeln geändert.

Settings
Base
Header Navigation
Hero And Page Shell
Index Page Layouts
About Page
Project And Blog Tables
Featured Project Cards
Blog Post Layout
Code Blocks
Entry Cards
Manga Vault
Responsive Layout
Motion

Das macht parallele Arbeit einfacher. Wenn Claude Code später ein Projekt-Feature baut, kann die Aufgabe gezielt heißen: Arbeite nur im Abschnitt Featured Project Cards oder Manga Vault. Das verhindert Konflikte nicht komplett, aber es macht sie seltener und lesbarer.

Wie Claude Code arbeitet

Claude Code arbeitet im eigenen Ordner auf dem Branch claude. Vor dem Bearbeiten wird der Zustand geprueft:

cd C:\Users\user0\Desktop\Projekte\newwaves.dev-claude
git branch --show-current
git status

Nach einem fertigen Feature wird direkt auf dem Claude-Branch committed:

git status
git add .
git commit -m "Beschreibung der Claude Änderung"

Wichtig ist, dass ein Commit nicht bedeutet, dass die Änderung schon live ist. Der Commit liegt erstmal nur auf claude. Erst wenn ich diesen Branch in main übernehme und main pushe, wird daraus ein Kandidat für GitHub und den VPS.

Änderungen in main übernehmen

Wenn ich ein Claude-Feature übernehmen will, gehe ich zurück in den Hauptordner und merge den Branch claude in main.

cd C:\Users\user0\Desktop\Projekte\newwaves.dev
git status
git merge claude

Wenn Git alles automatisch zusammenführen kann, landet das Claude-Feature in meinem lokalen main. Danach kann ich testen und den Stand zu GitHub pushen.

git push origin main

# auf dem VPS
cd /var/www/newwaves.dev
git pull

Was passiert bei Konflikten?

Das Hauptproblem bei paralleler Arbeit ist nicht, dass beide Tools dieselbe Website bearbeiten. Das eigentliche Problem entsteht, wenn beide dieselbe Stelle derselben Datei ändern. Dann kann Git nicht automatisch entscheiden, welche Version richtig ist.

<<<<<<< HEAD
/* Version aus main */
=======
/* Version aus claude */
>>>>>>> claude

In so einem Fall geht es nicht darum, blind eine ganze Datei zu nehmen. Die richtige Frage ist: Welche Regeln aus main müssen bleiben, welche Regeln aus claude müssen bleiben, und wie passen beide Features zusammen?

• Feature aus main erhalten.
• Feature aus claude erhalten.
• Doppelte Selektoren zusammenführen.
• Widersprüchliche CSS-Regeln bewusst entscheiden.
• Konfliktmarker vollständig entfernen.

Praktisch kann ich Codex dann sagen: Im Merge von claude nach main gibt es einen Konflikt in assets/css/style.css. Bitte löse ihn so, dass Feature 1 aus main und Feature 2 aus claude beide erhalten bleiben.

Claude vor dem finalen Merge aktualisieren

Wenn main sich weiterentwickelt hat, kann ich den aktuellen main-Stand zuerst in den Claude-Branch holen. So werden Konflikte früher im Claude-Ordner sichtbar und nicht erst beim finalen Merge.

cd C:\Users\user0\Desktop\Projekte\newwaves.dev
git pull origin main

cd C:\Users\user0\Desktop\Projekte\newwaves.dev-claude
git status
git merge main

Wenn dabei Konflikte entstehen, werden sie im Claude-Ordner gelöst. Danach kennt claude den aktuellen Stand von main, und der spätere Merge zurück nach main ist oft einfacher.

Meine Regeln für parallele Agent-Arbeit

• Codex arbeitet im bestehenden Ordner newwaves.dev.
• Claude Code arbeitet im neuen Ordner newwaves.dev-claude.
• Claude Code bekommt den Branch claude, der Hauptordner bleibt auf main.
• Beide Tools sollen möglichst nicht gleichzeitig am gleichen Featurebereich arbeiten.
• Nach jedem abgeschlossenen Feature wird committed.
• Große gemeinsame Dateien wie style.css bleiben in klare Abschnitte gegliedert.
• Der VPS zieht am Ende nur den fertigen main-Stand.

Damit ist Git für mich nicht nur ein Deploy-Werkzeug, sondern auch ein Arbeitsmodell. Codex und Claude Code können parallel helfen, aber Git entscheidet kontrolliert, wann Änderungen zusammengeführt werden. Das macht die Website nicht automatisch konfliktfrei, aber die Konflikte entstehen an einer Stelle, an der ich sie verstehen und gezielt lösen kann.