Git-Workflow mit Claude Code
Seit dem Worktrees-Setup hat sich strukturell wenig geändert. Was sich verschoben hat: ich entwickle den Großteil meiner Website inzwischen mit Claude Code im Worktree newwaves.dev-claude auf dem Branch claude.
Dieser Beitrag baut auf Git-Workflow mit Worktrees auf. Dort steht das Warum und Wie der Einrichtung, hier dokumentiere ich was sich in der Praxis durchgesetzt hat.
Mehr Claude Code in letzter Zeit
Anfangs war Claude Code ein Experiment neben Codex. Über die letzten Wochen ist daraus die Standard-Umgebung für größere Änderungen geworden: vom Landingpage-Redesign über die About-Seite mit dem ASCII-Globus bis zum kompletten Doku und Journal Split der Blog-Übersicht inklusive Footer auf allen Seiten. Codex bleibt parallel da, übernimmt aber zunehmend nur schnelle Pflegearbeiten direkt auf main.
Diese Verschiebung hat den Worktree-Workflow plötzlich wichtig gemacht. Solange Claude Code nur ab und zu lief, war die Trennung in zwei Ordner Theorie. Jetzt, wo ich täglich auf claude committe und mehrfach pro Session nach main merge, lerne ich die Eigenheiten des Setups in der Praxis kennen.
Vier Orte, ein logisches Repository
Mental hilft mir folgende Karte, wenn ich kurz nicht mehr weiß wo welcher Branch gerade lebt:
┌──────────────────────────────────────────────────────────────┐
│ WORKSTATION (Windows, lokal) │
│ C:\Users\user0\Desktop\Projekte\ │
└──────────────────────────────────────────────────────────────┘
│
┌───────────────────┴───────────────────┐
│ │
▼ ▼
┌──────────────────────────┐ ┌──────────────────────────┐
│ newwaves.dev/ │ │ newwaves.dev-claude/ │
│ ───────────────── │ │ ───────────────── │
│ Worktree (Codex/Live) │ │ Worktree (Claude Code) │
│ Branch: main │ │ Branch: claude │
│ │ │ │
│ Zweck: stabile Pflege, │ │ Zweck: experimentelle / │
│ finale Tests, Push │ │ parallele Agent-Arbeit │
│ nach GitHub. │ │ ohne Codex zu stören. │
└──────────────────────────┘ └──────────────────────────┘
│
│ beide Worktrees teilen sich EINE .git/ Datenbank
│ → Branches sind nur einmal gespeichert
│ → ein Branch kann immer nur in EINEM Worktree
│ gleichzeitig gecheckt-outet sein
│
│ git push origin main
│ git pull origin main
▼
┌──────────────────────────────────────────────────────────────┐
│ GITHUB (Remote, zentral) │
│ git@github.com:new-waves/newwaves.dev.git │
│ Sichtbarkeit: privat │
│ │
│ Branches: │
│ ├─ main ← stabiler Stand, Quelle für VPS │
│ └─ (claude) nicht gepusht (lokal-only per Default) │
│ │
│ Access: │
│ ├─ Workstation: SSH-Key (Authentication, read+write) │
│ └─ VPS: SSH Deploy-Key (READ-ONLY) │
└──────────────────────────────────────────────────────────────┘
│
│ git pull (read-only)
▼
┌──────────────────────────────────────────────────────────────┐
│ VPS (Ubuntu, Live-Server) │
│ /var/www/newwaves.dev/ │
│ │
│ Branch: main │
│ Rolle: serviert die statischen Files direkt an Besucher │
│ Kein Build, kein Restart, kein CMS │
└──────────────────────────────────────────────────────────────┘
Vier physische Orte, aber nur ein logisches Repository. Die zwei Worktrees auf der Workstation teilen sich denselben .git/ Ordner. Branches sind also nur einmal gespeichert. GitHub ist der zentrale Vermittler, der VPS ist read-only Konsument am Ende der Pipeline.
Was sich in der Praxis durchgesetzt hat
Drei Erkenntnisse haben sich aus dem regelmäßigen Arbeiten herauskristallisiert:
Claude bleibt lokal. Der Branch claude wird nicht zu GitHub gepusht. Der Merge nach main liest den lokalen Branch direkt aus der gemeinsamen .git/ Datenbank, ohne Umweg übers Netz. Anfangs habe ich oft git push origin claude als Safety-Net ausgeführt. Mittlerweile spare ich mir den Schritt. GitHub bleibt sauber, nur main wird remote sichtbar.
Branch ist nicht gleich Worktree. Klingt offensichtlich, aber im Alltag stolpert man trotzdem. Wenn ich aus dem Claude Worktree heraus versuche git checkout main zu machen, blockt Git, weil main bereits im anderen Worktree gecheckt-outet ist. Die Lösung ist nicht checkout, sondern cd ins andere Verzeichnis. Diese mentale Trennung hat sich erst nach mehreren Versuchen bei mir festgesetzt.
Pull vor dem Merge ist Sicherheit bei mehreren Geräten. Wenn ich nur an der Workstation arbeite, ist git pull origin main vor dem Merge meistens redundant. Aber sobald mein Laptop unterwegs aktiv wird (was inzwischen öfter passiert), kann mein lokales main hinter dem Remote-Stand liegen. Ohne Pull merge ich claude auf einen veralteten main, und der spätere Push wird abgewiesen mit non-fast-forward. Eine Sekunde Pull spart fünf Minuten Aufräumarbeit.
Mein heutiger Deploy-Ablauf
Eine Änderung, die mit Claude Code entstanden ist, läuft inzwischen so durch:
# 1. Im Claude Worktree arbeiten
cd C:\Users\user0\Desktop\Projekte\newwaves.dev-claude
# ... Claude Code editiert Dateien ...
# 2. Stagen und commit auf claude
git add <dateien>
git commit -m "Beschreibung der Änderung"
# 3. Wechsel ins main Worktree
cd C:\Users\user0\Desktop\Projekte\newwaves.dev
# 4. Sicherheit bei mehreren Geräten
git pull origin main
# 5. claude in main mergen (Fast-Forward erwartet)
git merge claude
# 6. main nach GitHub pushen
git push origin main
# 7. Auf dem VPS deployen
ssh <vps>
cd /var/www/newwaves.dev
git pull
Sieben Schritte, davon einer SSH. Was vor Wochen noch nach einem Workflow aussah, den ich konzentriert durchklicken musste, läuft inzwischen ohne Nachdenken. Das Setup hat die Frequenz verkraftet.
Was als Experiment begann, ist zur Selbstverständlichkeit geworden. Git ist nicht mehr nur Deploy-Mechanik, sondern die Schnittstelle zwischen mir, Codex und Claude Code, und die Stelle, an der entschieden wird, was überhaupt in die Live-Site darf.