Der Git Worktree-Trick, der Kaltstarts eliminiert

Git worktrees bieten eine leistungsstarke Möglichkeit, mehrere Branches gleichzeitig zu verwalten. Sie teilen sich die Historie eines einzigen Repositorys, aber jeder Worktree behält ein separates Arbeitsverzeichnis bei. Diese Trennung ist fantastisch für die parallele Entwicklung, etwa wenn Sie an mehreren Features gleichzeitig arbeiten oder mehrere AI-Coding-Agenten einsetzen.

Hier ist der Haken: Ein neuer Worktree ist fast leer. Git kopiert zwar Ihren Code, ignoriert jedoch absichtlich nicht verfolgte Dateien und Verzeichnisse. Das bedeutet, dass wichtige Komponenten wie node_modules für JavaScript-Projekte, ..env-Konfigurationsdateien oder das target/-Build-Verzeichnis von Rust komplett fehlen.

Folglich erfordert jeder neue Worktree einen vollständigen Kaltstart für Installation und Build-Prozess. Sie müssen Abhängigkeiten neu installieren, Code neu kompilieren und Caches neu generieren. Stellen Sie sich vor, Sie lassen fünf oder zehn Coding-Agenten laufen, die jeweils ihre eigene .environment benötigen.

Jeder Agent führt dann seinen eigenen npm install, cargo build oder ein anderes Setup aus. Dies vervielfacht den Aufwand: Fünf Agenten bedeuten fünf separate Installationen, fünf Kaltstarts und den fünffachen Speicherplatzverbrauch. Bevor überhaupt nützliche Arbeit geleistet wird, haben Sie bereits erhebliche Zeit, CPU-Zyklen und Gigabytes an Speicherplatz allein für die Vorbereitung aufgewendet.

Worktrunk, ein Open-Source Rust CLI, bietet mit seinem Befehl wt step copy-ignored eine clevere Lösung. Dieses Dienstprogramm nutzt Copy-on-Write (CoW), eine Dateisystemfunktion, um ausgewählte ignorierte Dateien fast sofort in einen neuen Worktree zu bringen, ohne eine herkömmliche vollständige Kopie durchzuführen.

Copy-on-Write ist ein genialer Trick: Dateien teilen sich anfangs dieselben zugrunde liegenden Festplattenblöcke. Wenn Sie eine Datei in einem Worktree ändern, kopiert das Dateisystem nur die geänderten Blöcke an einen neuen Ort. Dies bewahrt die Isolation zwischen den Worktrees und vermeidet gleichzeitig die anfänglichen Kosten für das Duplizieren riesiger Dateien. Es ist, als hätten Sie mehrere Kopien, die auf magische Weise nur dann Platz beanspruchen, wenn sie tatsächlich voneinander abweichen.

Dieser Ansatz beschleunigt das Setup drastisch. Das Video zeigt beeindruckende Gewinne: Das Kopieren eines 14 GB Rust-Build-Ordners sinkt angeblich von etwa zwei Minuten auf rund 20 Sekunden. Noch besser: Ein erster Build, der normalerweise etwa 68 Sekunden in einem frischen Worktree dauern würde, kann auf nur drei bis vier Sekunden fallen.

Dies sind vom Autor berichtete Ergebnisse, die das Potenzial auf Dateisystemen demonstrieren, die Reflinks unterstützen, wie macOS APFS oder Linux btrfs und XFS. Obwohl dies kein garantiertes Ergebnis für jedes Setup ist, veranschaulichen diese Zahlen die erhebliche Reduzierung der Kaltstartzeit, die CoW bieten kann, insbesondere bei der Arbeit mit großen Build-Caches oder node_modules-Verzeichnissen.

Bevor Sie sofortige Ergebnisse erwarten, ist es entscheidend, die Fähigkeiten Ihres Systems zu bestätigen. Copy-on-Write (CoW) oder Reflinks hängen von Ihrem Dateisystem und Ihrer Konfiguration ab. Viele Macs mit APFS und Linux-Dateisysteme wie btrfs und XFS unterstützen diese Funktion, aber nicht unterstützte Setups greifen auf eine herkömmliche, langsamere Kopie zurück.

Wichtig ist, dass sich CoW von Hardlinks oder gemeinsam genutzten, veränderbaren Verzeichnissen unterscheidet. Wenn Sie eine Datei in einem Worktree ändern, dupliziert das Dateisystem nur die geänderten Blöcke und stellt sicher, dass die Datei des anderen Worktrees unangetastet bleibt. Dies verhindert stille, unerwartete Änderungen in Ihren parallelen .environments.

Um die Auswirkungen wirklich zu verstehen, sollten Sie den Befehl wt step copy-ignored von Worktrunk an Ihrem tatsächlichen Projekt und Laufwerk testen. Messen Sie sowohl die verstrichene Zeit als auch die Festplattennutzung. Faktoren wie Paketmanager, Caches von Build-Tools und sogar .worktreeinclude-Konfigurationen (für eine granulare Kontrolle darüber, was kopiert wird) können die Ergebnisse beeinflussen.

Ein 14 GB großer Rust-Build-Ordner, der normal kopiert wird, benötigt beispielsweise etwa zwei Minuten und verbraucht zusätzliche 14 GB. Mit Reflinks kann dies auf etwa 20 Sekunden und praktisch null zusätzlichen Festplattenspeicher sinken. Dies reduziert die Cold-Build-Zeiten drastisch von etwa 68 Sekunden auf nur 3-4 Sekunden. Erfahren Sie mehr über die Optimierung Ihrer Git-Workflows für parallele KI-Agenten mit Worktrunk unter Worktrunk — Git worktree management for parallel AI agent workflows. Denken Sie daran, diese Zahlen sind illustrativ; Ihre Ergebnisse können abweichen!

Automatisieren Sie wt step copy-ignored, indem Sie es zu den Lifecycle-Hooks von Worktrunk hinzufügen. Dies stellt sicher, dass neue Worktrees automatisch nützliche Caches übernehmen, aber verwenden Sie eine .worktreeinclude-Datei, um festzulegen, welche ignorierten Pfade kopiert werden sollen. Schließen Sie zum Beispiel target/ für Rust-Projekte oder node_modules/ für JavaScript ein, aber schließen Sie temporäre Log-Dateien aus.

Wählen Sie Pfade bewusst aus. ..env-Dateien enthalten oft Geheimnisse und sollten im Allgemeinen nicht kopiert werden. Caches und generierte Artefakte können ebenfalls veraltet oder .environment-spezifisch sein, was potenziell zu schwer zu debuggenden Problemen führen kann. Nicht jede ignorierte Datei ist sicher oder nützlich zu teilen; wählen Sie sorgfältig.

Führen Sie diese Optimierung vorsichtig ein. Testen Sie sie zuerst an einem einzelnen Worktree. Überprüfen Sie die ordnungsgemäße Isolierung und die Korrektheit des Builds. Vergleichen Sie den Kaltstart des neuen Worktrees mit einem komplett sauberen Setup, um die Beschleunigung zu bestätigen, die so dramatisch sein kann, dass ein 68-sekündiger Rust-Build auf 3–4 Sekunden reduziert wird.

Sobald dies validiert ist, automatisieren Sie den Kopierschritt für den Agent-Workflow Ihres Teams. Dies gewährleistet Konsistenz und maximiert die Vorteile einer nahezu sofortigen Worktree-Bereitstellung, wodurch Kaltstarts in warme, produktive Anfänge verwandelt werden.

Was macht der copy-ignored-Befehl von Worktrunk?

Er kopiert gitignorierte Dateien von einem bestehenden Worktree in einen neuen, wobei Copy-on-Write verwendet wird, sofern das Dateisystem dies unterstützt.

Funktioniert Copy-on-Write auf jedem Laufwerk?

Nein. Es hängt von der Unterstützung durch das Dateisystem und die Plattform ab. APFS, btrfs und einige XFS-Konfigurationen unterstützen Reflinks; andernfalls kann das Kopieren mehr Zeit und Festplattenspeicher beanspruchen.

Ist es sicher, .env-Dateien in einen anderen Worktree zu kopieren?

Nur wenn dieselben Geheimnisse und Konfigurationen dort angemessen sind. Überprüfen Sie, was Sie einschließen, und vermeiden Sie es, Anmeldeinformationen mit nicht vertrauenswürdigen Projekten oder Agenten zu teilen.

Wie verwende ich den Befehl?

Installieren Sie Worktrunk und führen Sie wt step copy-ignored als Teil Ihres Worktree-Setups aus. Überprüfen Sie die Dokumentation von Worktrunk auf aktuelle Optionen und Konfigurationen.