vulp

vulp wyrósł z naszego własnego warsztatu, a nie z pomysłu na produkt. Prowadzimy kilkadziesiąt repozytoriów naraz - marki, panele, boty, narzędzia - i w pewnym momencie samo trzymanie w głowie, co gdzie czeka na commit, a co na push, zaczęło kosztować więcej niż sama robota. Standardowy git jest świetny do jednego repo i kompletnie bezradny wobec trzydziestu naraz.

Zbudowaliśmy więc narzędzie, które traktuje cały workspace jak jedną całość: skanuje wszystkie repo jednym przebiegiem, składa ich stan w jedną tabelę i pozwala zrobić tę samą operację na wielu naraz. Jeden twardy warunek postawiliśmy od początku - to samo narzędzie ma służyć i człowiekowi przy klawiaturze, i skryptowi w CI, bez dwóch osobnych kodów do utrzymania.

Kiedy prowadzisz jedno repo, sam git wystarcza w zupełności. Przy trzydziestu zaczyna się rytuał: wejdź do katalogu, sprawdź branch, zobacz czy drzewo czyste, sprawdź czy jesteś przed remote, wróć, następny. Zanim ogarniesz stan całości, mija kwadrans, a i tak łatwo przeoczyć to jedno repo, w którym siedzą niewypchnięte zmiany sprzed dwóch dni.

Najgorsze jest to, że ten koszt rośnie liniowo z liczbą repo, a uwaga człowieka nie. Im więcej katalogów do obejścia, tym większa szansa, że któryś zostanie pominięty - i to zwykle akurat ten, w którym coś wisi. Pętla po katalogach w bashu trochę pomaga, ale każda taka pętla to kolejny skrypt do napisania i utrzymania, pisany na nowo za każdym razem, gdy potrzebna jest inna operacja.

vulp zbiera ten stan w jedno miejsce i pozwala zrobić tę samą rzecz na wielu repo jednym poleceniem. Zamiast trzydziestu wywołań git status dostajesz jedną tabelę, a zamiast pętli po katalogach - jedną komendę z jasnym zakresem.

Najważniejsza decyzja architektoniczna zapadła na samym początku: cała logika żyje w rdzeniu, a CLI i TUI to tylko dwie skórki na to samo. CLI jest bezpromptowe i zwraca JSON, więc wpina się w skrypty i CI bez parsowania tekstu pisanego dla ludzi. TUI daje tę samą wiedzę człowiekowi, który woli patrzeć na tabelę niż pamiętać flagi.

Dzięki temu nowa operacja pojawia się od razu w obu miejscach. Dopisujesz ją raz, w rdzeniu, a i skrypt w cronie, i człowiek klawiszem dostają dokładnie to samo zachowanie - z tymi samymi zabezpieczeniami. Znika cała klasa rozjazdów w stylu "z ręki działa inaczej niż z pipeline'u".

Flaga wymagająca czystego drzewa to nie kaprys. Bez niej batch-push potrafi wypchnąć połowę niedokończonej roboty razem z tą gotową - i to na trzydziestu repo naraz, więc błędu nie cofniesz jednym ruchem. Guardrale w vulp są domyślnie zachowawcze: wolimy, żeby narzędzie odmówiło i kazało dopowiedzieć, niż żeby po cichu zrobiło coś nieodwracalnego.

Ta sama zasada działa przy operacjach masowych. Push na branch chroniony, wypchnięcie do repo, które wyprzedza lokalny stan, commit z brudnym drzewem tam, gdzie nie powinno go być - to wszystko są rzeczy, na których narzędzie ma się zatrzymać i zapytać, a nie zgadywać intencje. Automatyzacja bez hamulców jest szybsza dokładnie do pierwszej pomyłki.

Sam push to nie koniec historii - liczy się to, co realnie stoi na serwerze. Trzymamy tam lustro repozytoriów, a vulp po operacji porównuje stan lokalny z tym lustrem i pokazuje, gdzie kod w repo rozjechał się z tym, co faktycznie wdrożone. To wychwytuje klasyczną pułapkę: zmiana zacommitowana i wypchnięta, ale nigdy nie wdrożona, więc żyje tylko w gicie.

Do tego dochodzi codzienna robota wokół repo, która też idzie przez to samo narzędzie: przegląd PR-ów, issues i statystyk kontrybucji. Zamiast otwierać przeglądarkę do każdego repo z osobna, widzisz to zbiorczo, tam gdzie i tak już patrzysz na stan workspace'u.

Efekt jest nudny w najlepszym sensie tego słowa: sprawdzenie stanu workspace'u i wypchnięcie tego, co gotowe, przestało być porannym rytuałem klikania. Zostało jedno polecenie, które można odpalić z ręki albo zaplanować i zapomnieć - z tymi samymi zabezpieczeniami w obu przypadkach.

Głębszy zysk jest w tym, że narzędzie skaluje się razem z liczbą repo, a nie przeciwko niej. Dwudzieste repo nie dokłada rytuału, bo cały warsztat i tak jest obchodzony jednym przebiegiem. Nowa operacja to poprawka w rdzeniu, którą dostaje i CLI, i TUI, i skrypt w CI - jednym commitem, bez rozjazdu wersji.

Najważniejsze jest jednak to, że vulp nie jest osobnym gadżetem obok naszej pracy - jest tą samą warstwą, przez którą idzie i ręka, i automat. Człowiek klika, cron odpala, a robią dokładnie to samo, tak samo bezpiecznie. To jest różnica między skryptem, który działa u autora, a narzędziem, na którym da się polegać codziennie.