Polecenie git checkout służy w Git do dwóch kluczowych zadań: przełączania gałęzi oraz przywracania plików do wcześniejszego stanu. Dzięki niemu możesz bezpiecznie pracować równolegle nad różnymi wersjami strony WWW, cofać błędne zmiany w kodzie HTML, CSS czy JS i szybko odzyskiwać pliki – także w projektach nastawionych na dostępność cyfrową.
Co robi git checkout – krótki obraz całości
Z dokumentacji i popularnych samouczków wynika, że git checkout działa w dwóch podstawowych trybach.
Przełączanie gałęzi – git checkout <branch> zmienia aktywną gałąź oraz aktualizuje pliki katalogu roboczego do stanu zapisanego na tej gałęzi.
Przywracanie plików – git checkout [<commit>] -- <plik> (albo krócej git checkout <plik>) podmienia wersję wskazanych plików w katalogu roboczym na tę z wybranego commita lub z ostatniego commita na bieżącej gałęzi.
Innymi słowy: git checkout kopiuje wybraną wersję plików z historii Gita (lub ze stage) do katalogu roboczego i – jeśli dotyczy to gałęzi – przełącza HEAD na tę gałąź.
Jak Git patrzy na projekt – HEAD, katalog roboczy i stage
Aby w pełni zrozumieć zachowanie git checkout, warto pamiętać, że Git operuje na trzech „poziomach”:
- Historia (repozytorium) – wszystkie commity zapisane w
.git, w tym przeszłe wersje plików; - Stage (index) – obszar przygotowanych zmian, które wejdą do kolejnego commita;
- Katalog roboczy (working directory) – to, co faktycznie widzisz w swoim edytorze/konsoli.
Polecenie git checkout kopiuje pliki z historii lub ze stage do katalogu roboczego oraz może zmieniać to, na który commit/gałąź wskazuje HEAD.
Gdy wykonujesz git checkout <branch>, HEAD zaczyna wskazywać tę gałąź, a pliki robocze są aktualizowane do stanu z jej najnowszego commita. Gdy wykonujesz git checkout <commit> -- <plik>, HEAD zostaje na miejscu, a Git jedynie podmienia wersję konkretnego pliku w katalogu roboczym na tę z danego commita.
Przełączanie gałęzi za pomocą git checkout
Sprawdzenie dostępnych gałęzi
Aby wyświetlić lokalne gałęzie, użyj:
git branch
To polecenie wypisze listę branchy; przy aktualnej gałęzi zobaczysz gwiazdkę (*).
Przełączanie się na istniejącą gałąź
Najpopularniejsze zastosowanie git checkout to zmiana aktywnej gałęzi:
git checkout nazwa-gałęzi
Git zaktualizuje pliki projektu do stanu z najnowszego commita tej gałęzi, a wszystkie kolejne commity trafią właśnie na nią.
Przykład w projekcie WWW: pracujesz na main (stabilna wersja serwisu), a funkcjonalność rozwijasz na feature/a11y-skip-links (linki „Skip to content”).
Aby przejść na gałąź z dostępnościowymi zmianami, wykonaj:
git checkout feature/a11y-skip-links
Od tego momentu w katalogu roboczym zobaczysz kod dokładnie z tej gałęzi (np. nowe linki „Pomiń nawigację” w szablonach).
Tworzenie nowej gałęzi i jednoczesne przełączenie (-b)
Praktyczna składnia do startu pracy na świeżej gałęzi:
git checkout -b nowa-gałąź
Polecenie tworzy gałąź na podstawie bieżącego stanu i od razu na nią przełącza, więc możesz natychmiast pracować.
Przykład dla frontendu:
git checkout -b feature/form-labels
Tworzysz gałąź do poprawy etykiet formularzy (lepsza obsługa przez czytniki ekranu), nie dotykając stabilnej main.
Przełączenie na konkretny commit (tzw. „detached HEAD”)
Aby przejść bezpośrednio do konkretnego commita, użyj:
git checkout <hash-commita>
HEAD zacznie wskazywać commit zamiast gałęzi (tryb detached HEAD), a pliki w katalogu roboczym zostaną ustawione dokładnie tak, jak w tym punkcie historii.
To przydatne, gdy chcesz porównać stary layout lub tymczasowo zbudować demo z określonego momentu w historii.
Uwaga praktyczna: commity wykonane w trybie detached HEAD nie są przypisane do żadnej gałęzi. Aby ich nie zgubić, po zapisaniu zmian utwórz gałąź:
git checkout -b hotfix/naprawa.
Przywracanie plików za pomocą git checkout
Drugim dużym obszarem zastosowań git checkout jest odzyskiwanie plików – zarówno pojedynczych, jak i całych katalogów.
Odrzucenie lokalnych (niezatwierdzonych) zmian w jednym pliku
Gdy eksperymentujesz z CSS i chcesz wrócić do ostatnio zatwierdzonej wersji pliku, użyj:
git checkout -- styles/main.css
W wielu konfiguracjach zadziała też krótsza forma:
git checkout styles/main.css
Git przywróci plik do stanu z ostatniego commita na bieżącej gałęzi, a niezapisane lokalnie zmiany w tym pliku zostaną utracone.
Uwaga – działanie destrukcyjne: po takim poleceniu nie ma prostego sposobu na odzyskanie niezatwierdzonych zmian. Upewnij się, że naprawdę chcesz je odrzucić.
Rola -- w składni
Podwójny myślnik (--) informuje Gita, że to, co dalej, to ścieżki do plików, a nie nazwa gałęzi czy commita. To chroni przed błędną interpretacją, gdy nazwa pliku pokrywa się z nazwą gałęzi.
Przywrócenie wielu plików / całego katalogu roboczego
Aby przywrócić wiele plików (np. cały moduł frontendowy), wskaż katalog:
git checkout -- path/to/directory/
Aby przywrócić wszystkie pliki w repozytorium do stanu z ostatniego commita, użyj:
git checkout -- .
Kropka oznacza „bieżący katalog i podkatalogi”.
Uwaga – bardzo ryzykowne:
git checkout -- .wyczyści wszystkie niezatwierdzone zmiany w projekcie (HTML, CSS, JS, konfigurację itp.). W dużych zespołach stosuj tylko w pełni świadomie.
Przywracanie pliku z konkretnego commita
Gdy chcesz odtworzyć wersję pliku z określonego commita, wykonaj:
git checkout <hash-commita> -- ścieżka/do/pliku
To szczególnie pomocne, gdy plik był wielokrotnie modyfikowany i zależy Ci na powrocie do znanej, poprawnej wersji (np. sprzed zmian pogarszających dostępność).
Przykład:
git checkout 5d7a3f2 -- templates/form.html
Po przywróceniu pliku wykonaj trzy kroki, aby utrwalić zmiany:
- sprawdź różnice, np.
git diff; - dodaj plik do stage:
git add templates/form.html; - zapisz commit:
git commit -m "Przywróć poprawną wersję formularza z commit 5d7a3f2".
Przywrócenie usuniętego pliku
Aby odzyskać plik usunięty w historii, postępuj tak:
- znajdź commit, w którym plik jeszcze istniał (np.
git log); - przywróć go z tego commita:
git checkout <hash-poprawnego-commita> -- ścieżka/do/pliku; - jeśli plik został usunięty w ostatnim commicie, użyj skrótu:
git checkout HEAD^ -- ścieżka/do/pliku; - dodaj i zacommituj odzyskany plik, aby utrwalić stan.
Typowe scenariusze w tworzeniu stron WWW
Bezpieczne eksperymenty z layoutem i dostępnością
Testujesz nowy układ responsywny albo poprawiasz sekcję hero pod nawigację klawiaturą? Możesz pracować tak:
- utwórz gałąź eksperymentalną:
git checkout -b experiment/accessible-hero; - wprowadź zmiany w HTML/CSS/JS i sprawdź efekt;
- jeśli wynik jest nietrafiony, odrzuć wybrane pliki:
git checkout -- src/styles/hero.css; - jeśli część zmian jest wartościowa, zacommituj i zmerguj gałąź do
main.
Szybki hotfix na produkcji
Gdy po wdrożeniu wykryjesz błąd (np. złą kolejność nagłówków), skorzystaj z krótkiego obiegu poprawek:
- przełącz się na stabilną gałąź:
git checkout main; - utwórz gałąź hotfix:
git checkout -b hotfix/h1-order; - przywróć właściwą wersję pliku ze starego commita:
git checkout <hash-starej-dobrej-wersji> -- templates/article.html; - przetestuj, zacommituj i wdroż poprawkę.
Izolacja prac nad dostępnością
W projektach zorientowanych na dostępność równolegle prowadzi się duże refaktory UX/UI i drobne poprawki, takie jak:
- alt teksty,
- aria-label,
- kolejność fokusa,
- kontrasty kolorystyczne.
Warto tworzyć osobne gałęzie dla każdego obszaru, np.:
git checkout -b a11y/aria-landmarks
Dzięki git checkout możesz sprawnie przeskakiwać między istotnymi liniami rozwoju:
main– stabilna wersja serwisu,a11y/aria-landmarks– trwające prace nad landmarkami,feature/new-navigation– nowa nawigacja mobilna.
Każda gałąź ma własny zestaw commitów, a katalog roboczy zawsze odzwierciedla stan aktualnie wybranej gałęzi.
Pułapki i dobre praktyki przy użyciu git checkout
Uważaj na utratę niezatwierdzonych zmian
Polecenia typu git checkout -- plik lub git checkout -- . bezpowrotnie usuwają niezatwierdzone zmiany w katalogu roboczym.
Dobre praktyki przed użyciem poleceń destrukcyjnych:
- sprawdź
git status, aby zobaczyć, co zmieniłeś, - zrób szybki commit roboczy lub użyj
git stash, jeśli masz wątpliwości, - unikaj
git checkout -- .w dużych projektach bez pełnej świadomości skutków.
Rozróżniaj: git checkout vs git reset vs git revert
W szerszym zarządzaniu historią poszczególne komendy mają różne skutki:
git checkout– przełącza gałąź lub podmienia pliki w katalogu roboczym na wersje z historii;git reset– przesuwa wskaźniki (HEAD/gałąź), może modyfikować również stage i katalog roboczy; służy do „cofania się” do wcześniejszego commita;git revert– tworzy nowy commit odwracający zmiany wprowadzone przez wskazany commit, zachowując spójność historii.
W kontekście pojedynczych plików (np. cofnięcie jednej modyfikacji CSS) git checkout <commit> -- <plik> bywa prostsze niż git reset lub git revert całego commita.
Detached HEAD – kiedy to problem?
Tryb detached HEAD po git checkout <hash-commita> jest w porządku do podglądu starego stanu projektu. Kłopot zaczyna się, gdy zrobisz tam commity i zapomnisz utworzyć gałąź – ryzykujesz ich „zgubienie”.
Bezpieczny schemat: pracuj i commituj, a następnie utwórz gałąź, aby przypiąć te commity do nazwanego miejsca: git checkout -b nazwa-nowej-gałęzi.
git checkout a nowsze polecenia (git switch, git restore)
Nowsze wersje Gita rozdzieliły odpowiedzialności: git switch służy do przełączania gałęzi, a git restore do przywracania plików. Mimo to w wielu materiałach, narzędziach i pipeline’ach CI/CD wciąż spotkasz klasyczne git checkout.
Z punktu widzenia programisty webowego i specjalisty od dostępności warto rozumieć git checkout niezależnie od tego, czy na co dzień używasz switch/restore, ponieważ:
- ułatwia to czytanie istniejących tutoriali,
- pozwala zrozumieć zachowanie narzędzi (deploy, CI) korzystających z
git checkout, - pomaga trafniej diagnozować błędy w pracy z repozytorium.
