worktrunk ist ein in Rust geschriebenes Kommandozeilenwerkzeug, das sich um Git-Worktrees kuemmert. Es presst Anlegen, Wechseln, Zusammenfuehren und Aufraeumen in wenige Befehle und kann Projekt-Hooks ausfuehren, die in einem frischen Ordner Abhaengigkeiten installieren oder einen Dienst starten. Die Startseite des Projekts sagt es deutlich: gebaut fuer Ablaeufe, die Agenten parallel laufen lassen. Wer drei oder vier Coding-Agenten auf ein Repository ansetzt, braucht es am ehesten. Es laeuft unter Windows, macOS und Linux, die aktuelle Fassung ist 0.81.

Warum Worktrees einen eigenen Befehl wollen

Git-Worktrees sind fuer sich nicht kompliziert: ein Repository kann mehrere Branches in getrennte Ordner auschecken, ohne dass sie sich stoeren und ohne Staendiges Wegstashen. Die Reibung liegt in der Bedienung. Der native Befehl will Pfade und Branchnamen, und nach dem Wechsel tippt man selbst noch cd. Bei fuenf oder sechs Ordnern lebt im Kopf, welcher Branch wo steht und ob er hinter main zurueckliegt.

Schaerfer wird es mit Agenten. Laesst man einen Agenten in einem Repository arbeiten, hinterlaesst er ein Arbeitsverzeichnis im Zwischenzustand; ein zweiter tritt dem ersten auf die Fuesse. Jedem Agenten einen eigenen Worktree zu geben ist die sauberste Antwort, und das tagtaeglich von Hand zu tun ist der laestige Teil.

wt switch wechselt Ordner, nicht Branches

wt switch nimmt einen Branchnamen. Gibt es den Branch nicht, legt es einen Worktree dafuer an, gibt es ihn, wechselt es dorthin. Der Unterschied zum nativen Befehl ist die Shell-Integration: nach der Installation nimmt der Wechsel das Arbeitsverzeichnis des Terminals mit, ein zweites cd entfaellt. Es kann auch einen Befehl mitnehmen, dessen Argumente hinter einem doppelten Bindestrich stehen, womit Anlegen, Betreten und Start einer Agentensitzung ein Schritt werden.

Ein neuer Baum startet mit leeren Abhaengigkeiten und Einstellungen, und Hooks fuellen sie. Die Projektkonfiguration kann eine Startroutine halten, Pakete installieren, eine Datenbank initialisieren, einen lokalen Dienst starten, ausgefuehrt bei jedem neuen Baum. Vor dem Hook fragt worktrunk, ob Sie dem Projekt vertrauen, damit das Klonen eines Repository nicht still fremde Befehle ausfuehrt.

wt list: alle Baeume in einer Tabelle

Der Befehl laeuft und eine Tabelle kommt zurueck. Jede Zeile ist ein Worktree und nennt Branch, Zustand des Arbeitsbereichs, Commit, Vorlauf oder Rueckstand gegenueber main, Abstand zum Remote, Zeit und Text des letzten Commits. Ein gerade angelegter Baum ist als ladend markiert und fuellt sich Sekunden spaeter.

Die Zustandsspalte zeigt uncommittete Aenderungen, Konflikte und einen laufenden Merge, ohne dass Sie jeden Ordner besuchen. Die Vorlaufspalte zeigt, welcher Baum hinter main liegt und welcher schon gepusht ist. Die Textspalte sagt mit den erzeugten Commit-Notizen in einer Zeile, was ein Baum tut.

Zusammenfuehren und Aufraeumen sind feste Ablaeufe

Arbeit braucht ein Ende. wt merge committet die Aenderungen im aktuellen Baum, rebased auf den Zielbranch, spult vor und entfernt danach Worktree und Branch, alles im Hintergrund, damit Sie weitertippen koennen. Es unterstuetzt auch einen Merge-Commit fuer Repositories, die die Branch-Historie behalten wollen.

Wird ein Baum nicht mehr gebraucht, raeumt wt remove ihn weg. Ein entfernter Baum verschwindet nicht sofort, er landet in .git/wt/trash, ein Fehlgriff laesst sich zuruecknehmen. Mit der Zeit raeumt prune auf: Baeume, deren Branch schon im Standardbranch steckt, gehen, nicht zusammengefuehrte und frisch angelegte werden uebersprungen, und ein Mindestalter bestimmt das Tempo.

Ein Ordner je Agent

Bei parallelen Agenten stoeren die ignorierten Dateien am meisten: node_modules, Bauausgabe, lokale Umgebungsvariablen. Ein neuer Baum hat davon nichts, also beginnt der Agent mit einer Neuinstallation. wt kann ignorierte Dateien aus dem Quellbaum kopieren und schreibt Werte um, die kollidieren wuerden, Portnummern und Datenbanknamen etwa, damit zwei Baeume nicht um denselben Port streiten.

worktrunk steht unter MIT und Apache 2.0, der Quellcode liegt auf GitHub, die Dokumentation ist vollstaendig. Es bindet sich an keinen bestimmten Agenten: jedes Werkzeug, das sich im Terminal starten laesst, kommt ueber dieses Argument in den neuen Baum.

Lohnt es sich

Wer nur einen Branch pflegt, braucht es nicht, natives git genuegt. Es passt in zwei Lagen: mehrere unabhaengige Funktionslinien gleichzeitig vorantreiben, oder zwei bis drei Agenten parallel an einem Repository arbeiten lassen. Das eine spart Ordnerverwaltung, das andere die Suche nach dem Ueberschreiben.

Der Preis ist eine weitere Befehlsebene. wt bringt eigene Unterbefehle und Konfiguration mit, ein falscher Hook verhindert den Start eines neuen Baums, und die Shell-Integration ist Voraussetzung: ohne sie faellt das Wechseln auf Handarbeit zurueck.

worktrunk macht etwas Kleines: es verschiebt Git-Worktrees von einem Merkmal, von dem man weiss, zu etwas, das man taeglich benutzt. Ein neuer Mechanismus wurde nicht erfunden. Anlegen, Zustand lesen, Zusammenfuehren und Aufraeumen wurden vier Befehle, die in die Hand passen, dazu eine Hook-Schicht, damit ein frischer Ordner allein hochkommt. In einem Ablauf mit parallelen Agenten ist diese Bequemlichkeit ihren Preis wert.