vulp

vulp ist aus unserer eigenen Werkstatt gewachsen, nicht aus einer Produktidee. Wir betreiben Dutzende Repositorys gleichzeitig - Marken, Panels, Bots, Werkzeuge - und irgendwann kostete allein das Im-Kopf-Behalten, welches Repo auf einen Commit und welches auf einen Push wartet, mehr als die Arbeit selbst. Das normale git ist hervorragend für ein einzelnes Repo und völlig hilflos gegenüber dreißig gleichzeitig.

Also haben wir ein Werkzeug gebaut, das den gesamten Workspace als eine Einheit behandelt: Es scannt jedes Repo in einem einzigen Durchlauf, fügt ihren Zustand zu einer Tabelle zusammen und lässt dieselbe Operation über viele auf einmal laufen. Eine harte Bedingung haben wir von Anfang an gestellt - dasselbe Werkzeug soll sowohl dem Menschen an der Tastatur als auch dem Skript in der CI dienen, ohne zwei getrennte Codebasen pflegen zu müssen.

Wenn Sie ein einzelnes Repo betreiben, reicht das normale git vollkommen. Bei dreißig wird es zum Ritual: ins Verzeichnis wechseln, den Branch prüfen, sehen ob der Baum sauber ist, prüfen ob Sie dem Remote voraus sind, zurück, das nächste. Bis Sie den Zustand des Ganzen erfasst haben, ist eine Viertelstunde vergangen, und trotzdem übersehen Sie leicht genau das eine Repo, in dem seit zwei Tagen nicht gepushte Änderungen liegen.

Das Schlimmste ist, dass dieser Aufwand linear mit der Zahl der Repos wächst, die Aufmerksamkeit des Menschen aber nicht. Je mehr Verzeichnisse zu durchlaufen sind, desto höher die Chance, dass eines übersprungen wird - und es ist meist genau das, in dem etwas hängt. Eine Shell-Schleife über die Verzeichnisse hilft ein wenig, aber jede solche Schleife ist ein weiteres Skript zum Schreiben und Pflegen, jedes Mal neu geschrieben, wenn eine andere Operation gebraucht wird.

vulp zieht diesen Zustand an einen Ort und lässt Sie dieselbe Sache über viele Repos mit einem einzigen Befehl erledigen. Statt dreißig git-status-Aufrufen bekommen Sie eine Tabelle, und statt einer Schleife über Verzeichnisse - einen Befehl mit klarem Geltungsbereich.

Die wichtigste architektonische Entscheidung fiel ganz am Anfang: Die gesamte Logik lebt im Kern, und CLI und TUI sind nur zwei Häute über derselben Sache. Die CLI ist prompt-frei und gibt JSON zurück, also fügt sie sich in Skripte und CI ein, ohne für Menschen gedachten Text zu parsen. Die TUI gibt dasselbe Wissen einem Menschen, der lieber auf eine Tabelle schaut als sich Flags zu merken.

Dadurch taucht eine neue Operation an beiden Stellen auf einmal auf. Sie schreiben sie einmal, im Kern, und sowohl das Cron-Skript als auch der Mensch per Tastendruck bekommen genau dasselbe Verhalten - mit denselben Sicherungen. Eine ganze Klasse von Diskrepanzen im Stil "von Hand läuft es anders als aus der Pipeline" verschwindet.

Das Flag, das einen sauberen Baum verlangt, ist keine Laune. Ohne es kann ein Batch-Push halbfertige Arbeit zusammen mit der fertigen ausliefern - und das über dreißig Repos auf einmal, sodass der Fehler nicht mit einem Zug rückgängig zu machen ist. Die Guardrails in vulp sind standardmäßig konservativ: Uns ist lieber, das Werkzeug verweigert und verlangt Eindeutigkeit, als dass es still etwas Unumkehrbares tut.

Dasselbe Prinzip gilt bei Massenoperationen. Ein Push auf einen geschützten Branch, ein Push in ein Repo, das dem lokalen Zustand voraus ist, ein Commit mit schmutzigem Baum dort, wo es keinen geben sollte - das sind alles Dinge, bei denen das Werkzeug anhalten und fragen soll, statt die Absicht zu erraten. Automatisierung ohne Bremsen ist genau bis zum ersten Fehler schneller.

Der Push selbst ist nicht das Ende der Geschichte - es zählt, was wirklich auf dem Server steht. Wir halten dort einen Spiegel der Repositorys, und nach einer Operation vergleicht vulp den lokalen Zustand mit diesem Spiegel und zeigt, wo der Code in einem Repo von dem abweicht, was tatsächlich deployt ist. Das fängt die klassische Falle ab: eine Änderung committet und gepusht, aber nie deployt, sodass sie nur in git lebt.

Dazu kommt die tägliche Arbeit rund um die Repos, die ebenfalls durch dasselbe Werkzeug läuft: das Durchsehen von PRs, Issues und Beitragsstatistiken. Statt für jedes Repo einzeln einen Browser zu öffnen, sehen Sie es gesammelt, genau dort, wo Sie ohnehin schon auf den Workspace-Zustand schaust.

Der Effekt ist langweilig im besten Sinne des Wortes: Den Zustand des Workspace zu prüfen und zu pushen, was fertig ist, ist kein morgendliches Klick-Ritual mehr. Übrig bleibt ein Befehl, den man von Hand ausführen oder einplanen und vergessen kann - mit denselben Sicherungen in beiden Fällen.

Der tiefere Gewinn liegt darin, dass das Werkzeug mit der Zahl der Repos skaliert und nicht gegen sie. Das zwanzigste Repo fügt kein Ritual hinzu, weil die ganze Werkstatt ohnehin in einem Durchlauf durchgegangen wird. Eine neue Operation ist eine Korrektur im Kern, die die CLI, die TUI und das CI-Skript alle bekommen - in einem einzigen Commit, ohne Versions-Drift.

Am wichtigsten aber ist, dass vulp kein separates Gadget neben unserer Arbeit ist - es ist dieselbe Schicht, durch die sowohl eine Hand als auch eine Automatisierung geht. Ein Mensch klickt, cron feuert, und sie tun genau dasselbe, genauso sicher. Das ist der Unterschied zwischen einem Skript, das beim Autor läuft, und einem Werkzeug, auf das man sich täglich verlassen kann.