Wbudowany git

Projekt Restorm jest stworzony do tego, aby żyć w repozytorium git. Integracja idzie dalej niż zwykłe git commit: rozumie format i potrafi rozwiązać konflikt na poziomie encji biznesowych, a nie wierszy YAML.

Pierwsze kroki

Nie ma nic do skonfigurowania. Gdy tylko otwarty plik .restorm znajduje się w repozytorium git, powierzchnie gita stają się aktywne.

Restorm korzysta z lokalnie zainstalowanego git: nie trzeba podawać danych uwierzytelniających ani zarządzać tokenami w aplikacji. Zasada jest prosta — jeśli git push działa w terminalu, działa też w aplikacji Restorm. Git jest uruchamiany z wyłączonymi monitami: repozytorium, które zażądałoby hasła, kończy się natychmiastowym błędem z komunikatem gita, zamiast blokować interfejs.

Komórka GIT na pasku stanu

Dwa przyciski, Wypchnij i Pobierz, każdy z plakietką (kropką, nigdy liczbą), gdy jest coś do wysłania albo dostępna jest nowsza wersja do pobrania.

Menu Git na pasku tytułu udostępnia te same akcje, a dodatkowo Odśwież, Przywróć wersję serwera oraz Historia.

Komórka GIT na pasku stanu: Odśwież, Wypchnij i Pobierz, przy czym dwa ostatnie noszą plakietkę, a następnie Historia. Otwarta jest podpowiedź „Wypchnij do repozytorium”.

Wypychanie

Okno dialogowe wypychania pokazuje gotową już wiadomość commita, generowaną deterministycznie na podstawie strukturalnego diffu — bez modelu językowego. Jeden wiersz na zmienioną encję (żądanie, scenariusz, folder, folder zmiennych), nigdy jeden wiersz na pole.

Selektor języka wiadomości, niezależny od języka interfejsu, wraz z przełącznikiem ustawiającym go jako wartość domyślną.
Edytowalny tytuł, z licznikiem pomocniczym przy 72 znakach.
Wieloliniowa treść.

Zatwierdzenie wykonuje po kolei: zapis, git add, commit, push.

Pobieranie

Restorm najpierw zapisuje, a następnie pobiera i scala.

Czyste scalenie: drzewo oraz otwarte zakładki odświeżają się w miejscu.

Konflikt: otwiera się widok rozwiązywania z czterema panelami.

Widok rozwiązywania konfliktu z czterema panelami: lista konfliktów po lewej, Twoja wersja, wersja serwera — rozbieżne adresy URL są obramowane na czerwono — oraz panel „Rozwiązano” wypełniony po wybraniu własnej wersji.

Panel	Zawartość
Lista konfliktów	Encje pozostające w konflikcie
Twoja wersja	Tylko do odczytu
Wersja serwera	Tylko do odczytu
Rozwiązano	Edytowalny — to on zostanie zapisany

Rzecz najważniejsza: każdy panel pokazuje encję w jej prawdziwym edytorze — żądanie HTTP w edytorze HTTP, scenariusz w edytorze scenariuszy. Nie rozwiązuje się znaczników <<<<<<< w YAML, lecz porównuje dwa żądania.

Po każdej stronie znajduje się przycisk „Użyj tej wersji”, a rozbieżne pola są podświetlone na czerwono — gdy różni się tylko jedno pole, panel otwiera się od razu na właściwej zakładce.

Dokumentacja API folderu zmiennych rozwiązuje się automatycznie (wygrywa nowsza wersja).

Anuluj wykonuje git merge --abort. Zamknięcie aplikacji w trakcie rozwiązywania sprawia, że przy następnym uruchomieniu Restorm proponuje przerwanie scalania.

Sprawdzanie w tle (semi-pull)

Restorm okresowo sprawdza, czy istnieje nowsza wersja — nigdy nie scalając samodzielnie. Trzy wyzwalacze: zauważona zmiana w .git, otwarcie pliku oraz czasomierz, którego częstotliwość ustawia się w Ustawienia ▸ Git (Wyłączone, 15 min, 30 min, 1 h, 4 h, 12 h, 24 h).

Powiadomienie „Dostępna aktualizacja” proponuje wówczas Pull now.

Zewnętrzna zmiana pliku

Jeśli plik zmienił się na dysku od chwili otwarcia, zapis zostaje odrzucony, a Restorm prosi o wybór między Wczytaj ponownie i Zachowaj swoją wersję.

Dlaczego diffy są czytelne

Dwie właściwości formatu, opisane w Projekty i pliki .restorm: kanoniczna kolejność kluczy oraz stabilnie wyprowadzane identyfikatory.

Konsekwencja: otwarcie i ponowny zapis bez żadnej zmiany nie generuje żadnego diffu, a dwie osoby dodające to samo żądanie w tym samym miejscu tworzą encje, które scalanie potrafi sparować.

Historia

Git ▸ Historia otwiera widok dwupanelowy: listę commitów z rynienką gałęzi oraz szczegóły po prawej. Menu kontekstowe commita pozwala przywrócić tę wersję.

Przez MCP

Cztery narzędzia, w edycji Pro: git_commit_push (krok 1 z 2 — zwraca token przeglądu, tytuł, treść oraz diff dla każdej encji, nic nie zapisując), git_confirm_push (krok 2 z 2 — odrzucany, jeśli projekt zmienił się od momentu przeglądu), git_pull oraz git_resolve_conflicts.

Podział na dwa etapy jest zamierzony: agent nie może wypchnąć zmian bez uprzedniego przedstawienia diffu.