git show to scyzoryk do zaglądania w głąb obiektów Git. Najczęściej rzucasz nim w commit, żeby zobaczyć jego metadane (autor, data, opis) razem z konkretnym diffem zmian. Ale to nie wszystko: git show potrafi pokazać też tagi, drzewa katalogów, a nawet zawartość pojedynczego pliku w wybranej wersji historii. Jeśli kiedyś chciałeś sprawdzić „co właściwie zmienił ten jeden commit?” albo „jak wyglądał ten plik trzy commity temu?”, to jest twoje narzędzie.
Składnia i najważniejsze opcje
Podstawowa forma: git show [opcje] [. Bez argumentu pokazuje ostatni commit (HEAD).
--stat— zamiast pełnego diffa pokazuje skrót: które pliki ruszone i ile linii doszło/zniknęło.--name-only— wyłącznie lista zmienionych plików, bez treści zmian.--name-status— lista plików z literką statusu (A dodany, M zmodyfikowany, D usunięty).-slub--no-patch— pomija diff, zostawia samą „główkę” commita (opis, autor).--oneline— kompresuje nagłówek commita do jednej linii.--pretty=/--format=— własny układ nagłówka, np.--pretty=fullerpokazuje też datę commitera.--color-words— diff podświetlany słowo po słowie zamiast całych linii (czytelniejszy przy drobnych zmianach).
Przykłady użycia
git show— pełen diff i opis ostatniego commita. Najszybszy sposób „co ja właśnie zacommitowałem?”.git show a1b2c3d— pokazuje konkretny commit po jego skróconym hashu.git show HEAD~2— zagląda w commit dwa kroki wstecz od bieżącego.git show HEAD:config.yml— wypluwa zawartość plikuconfig.ymlw wersji z aktualnego commita, bez zmieniania tego co masz na dysku.git show --stat v1.4.0— dla taga z opisem pokaże informacje o tagu i podsumowanie wskazywanego commita.
Częste błędy i pułapki
Najczęstsza wpadka to składnia commit:plik — pamiętaj o dwukropku. git show HEAD plik.txt (ze spacją) pokaże tylko zmiany dotyczące tego pliku w commicie, a git show HEAD:plik.txt (z dwukropkiem) wypisze całą jego zawartość. To dwie różne rzeczy, łatwo pomylić.
Druga sprawa: git show commita scalającego (merge) domyślnie potrafi nie pokazać diffa albo pokazać go w skróconej formie — to nie błąd, tylko sposób, w jaki Git traktuje połączenia dwóch gałęzi. Dorzuć wtedy -m, żeby zobaczyć zmiany względem każdego rodzica osobno.
I drobiazg: jeśli podasz hash, którego nie ma w repozytorium, dostaniesz fatal: bad object. Sprawdź wtedy git log, czy aby na pewno taki commit istnieje i czy nie pomyliłeś znaku w skrócie.
Powiązane komendy: git log, git diff, git cat-file, git rev-parse.