Jak cofnąć commit i odzyskać zmiany w Git: 10 komend ratunkowych

Ten artykuł nie jest listą egzotycznych flag do zapamiętania, lecz praktycznym zestawem komend Git, które warto znać, gdy repozytorium przestaje zachowywać się jak spokojna sekwencja pull → commit → push.

Zanim użyjesz komendy ratunkowej: cztery warstwy Git

Słowo „cofnąć” jest nieprecyzyjne. Ta sama zmiana może znajdować się w czterech miejscach, a pomylenie ich jest częstą przyczyną utraty danych:

Zacznij od git status, a przed operacją zmieniającą historię utwórz referencję do obecnego commita:

git status
git branch rescue-before-fix HEAD

Taki branch chroni aktualny commit, ale nie zapisuje zmian roboczych ani plików nieśledzonych. Jeżeli to one są najcenniejsze, nie uruchamiaj reset --hard, restore, clean ani git gc. Najpierw zrób kopię katalogu poza repozytorium lub bezpieczny commit ratunkowy na osobnym branchu. Sprawdź, czy kopia obejmuje także pliki ukryte i ignorowane.

1. git stash: tymczasowy schowek na zmiany

git stash push zapisuje stan śledzonych plików w osobnym wpisie i cofa te zmiany w katalogu roboczym. Domyślnie nie obejmuje plików nieśledzonych ani ignorowanych, dlatego czysty wynik zależy od użytych flag. To przydatna opcja, gdy musisz szybko przełączyć branch lub zrobić hotfix bez mieszania go z aktualną pracą.

# Schowaj zmiany w śledzonych plikach
git stash
 
# Schowaj także nowe, nieśledzone pliki
git stash push -u
 
# Schowaj także pliki ignorowane — używaj ostrożnie
git stash push -a
 
# Schowaj zmiany z opisem
git stash push -m "Work in progress: navbar"
 
# Zobacz listę stashy
git stash list
 
# Sprawdź pełny patch przed przywróceniem
git stash show -p --include-untracked stash@{0}
 
# Przywróć ostatni stash i usuń go ze stosu
git stash pop
 
# Przywróć stash bez usuwania go ze stosu
git stash apply
 
# Przywróć konkretny stash
git stash apply stash@{1}
 
# Odtwórz pracę na branchu zaczynającym się w pierwotnym punkcie
git stash branch recovered-wip stash@{0}

Jeżeli chcesz odłożyć tylko wybrane pliki, podaj ścieżkę na końcu:

git stash push -m "Tylko formularz kontaktowy" -- src/components/ContactForm.tsx

Jeśli git stash pop zakończy się konfliktem, wpis pozostaje na liście. Rozwiąż konflikt i usuń go ręcznie dopiero po sprawdzeniu rezultatu. git stash branch bywa bezpieczniejszy, gdy stash powstał dawno temu i aktualny branch znacznie się zmienił.

stash jest wygodny, ale łatwo zamienić go w mały śmietnik. Jeśli praca ma potrwać dłużej niż kilka godzin, zwykle lepszy będzie mały commit roboczy na osobnym branchu, najlepiej wypchnięty do prywatnego brancha zdalnego.

2. git cherry-pick: jak przenieść konkretny commit?

git cherry-pick kopiuje zmianę z wybranego commita na aktualny branch i nie przenosi całej historii brancha, ale tworzy nowy commit z tym samym diffem.

# Znajdź hash commita na branchu źródłowym
git log --oneline feature-branch
 
# Przełącz się na branch docelowy
git switch main
 
# Przenieś jeden commit
git cherry-pick abc1234
 
# Przenieś kilka commitów
git cherry-pick abc1234 def5678
 
# Nałóż zmianę bez automatycznego commita
git cherry-pick --no-commit abc1234

Gdy pojawi się konflikt, Git zatrzyma operację i poczeka na decyzję:

git cherry-pick abc1234
 
# Rozwiąż konflikty w plikach
git add <resolved-files>
git cherry-pick --continue
 
# Albo wycofaj całą operację
git cherry-pick --abort

cherry-pick najlepiej działa dla małych, niezależnych commitów: poprawki buga, drobnej zmiany konfiguracyjnej, jednego refaktoru. Jeśli przenosisz w ten sposób połowę brancha, prawdopodobnie lepszy będzie merge albo rebase.

3. git reflog: jak odzyskać zgubiony commit?

Wskaźnik HEAD zmienia się przy commitach, resetach, przełączeniach branchy i rebase. git reflog zapisuje te ruchy lokalnie, dlatego często pozwala odzyskać commity, które zniknęły z normalnego git log.

git reflog
 
# Przykładowy wynik:
# abc1234 HEAD@{0}: commit: Popraw walidację formularza
# def5678 HEAD@{1}: reset: moving to HEAD~3
# 91ab2cd HEAD@{2}: checkout: moving from main to feature/login

Typowy scenariusz: robisz reset --hard, orientujesz się, że to był błąd, a potem szukasz poprzedniego stanu w reflogu.

# Błędna operacja
git reset --hard HEAD~3
 
# Szukasz utraconego commita
git reflog
 
# Bezpieczniej najpierw utworzyć branch ratunkowy
git switch -c recovered-work def5678

Reflog zapisuje ruchy referencji, a nie każdą wersję pliku. Może odzyskać commit sprzed reset --hard, ale nie gwarantuje odzyskania niezacommitowanej pracy nadpisanej w working tree. W takim przypadku sprawdź lokalną historię IDE, snapshoty systemu plików i backupy; kolejne operacje zapisu mogą zmniejszać szanse narzędzi odzyskujących dane.

Reflog pomaga też przy usuniętym branchu:

git branch -D feature-important
 
git reflog
 
# Po znalezieniu ostatniego commita brancha:
git switch -c feature-important abc1234

4. git reset i git revert: dwa sposoby cofania commita

git reset przesuwa aktualny branch na inny commit i w zależności od trybu może zostawić zmiany w staging area, w working directory albo usunąć je z plików roboczych.

git reset --soft HEAD~1
git reset --mixed HEAD~1
git reset --hard HEAD~1

Najprostsze rozróżnienie wygląda tak:

git revert nie przepisuje historii. Dodaje nowy commit, który odwraca konkretną zmianę:

git revert abc1234

reset --hard nie ogranicza się do „cofniętego commita”: nadpisuje także inne lokalne zmiany w śledzonych plikach, a kolidujące pliki nieśledzone mogą zostać usunięte. Przed jego użyciem sprawdź wszystkie cztery warstwy i utwórz kopię. Jeżeli chcesz tylko usunąć plik ze staging area, użyj git restore --staged -- plik; jeżeli chcesz porzucić jego zmiany robocze, użyj git restore --worktree -- plik dopiero po obejrzeniu git diff.

Jeśli chcesz cofnąć zmianę, która trafiła już na branch używany przez zespół albo CI/CD, zacznij od revert. O pracy z automatyzacją po stronie repozytorium więcej piszę w artykule o CI/CD dla Next.js.

5. git bisect: znajdź commit, który zepsuł projekt

git bisect prowadzi Cię przez historię metodą wyszukiwania binarnego. Zamiast ręcznie sprawdzać 40 commitów po kolei, oznaczasz znany dobry i znany zły punkt, a Git sam wybiera kolejne commity do testowania.

git bisect start
git bisect bad
git bisect good abc1234
 
# Git przełączy repozytorium na commit w środku zakresu.
# Testujesz aplikację i oznaczasz wynik:
git bisect good
# albo:
git bisect bad
 
# Po znalezieniu winnego commita wracasz do normalnej pracy:
git bisect reset

Jeśli masz test, który jednoznacznie wykrywa problem, możesz zautomatyzować proces:

git bisect start HEAD abc1234
git bisect run npm test

Komenda uruchamiana przez git bisect run musi zwracać 0 dla commita dobrego, kod 1–127 z wyjątkiem 125 dla złego oraz 125, jeśli rewizji nie da się przetestować i należy ją pominąć. Pozostałe kody przerywają bisect. Test powinien być deterministyczny; niestabilny test albo błąd instalacji zależności może wskazać fałszywego winowajcę.

6. git rebase -i: uporządkuj lokalną historię

Interaktywny rebase pozwala zmieniać kolejność commitów, poprawiać opisy, łączyć małe commity i usuwać niepotrzebne zmiany przed review.

git rebase -i HEAD~3

Git otworzy edytor z listą commitów:

pick abc1234 Add login form
pick def5678 Fix typo
pick ghi9012 Add validation
 
# pick = użyj commit
# reword = zmień opis commita
# squash = połącz z poprzednim i edytuj opis
# fixup = połącz z poprzednim i odrzuć opis
# drop = usuń commit

Typowe sprzątanie wygląda tak:

pick abc1234 Add login form
fixup def5678 Fix typo
squash ghi9012 Add validation

Interaktywny rebase ma największy sens przed wypchnięciem brancha albo przed otwarciem pull requesta. Gdy commit jest już używany przez inne osoby, rebase zaczyna generować koszt synchronizacji.

7. git log: szukanie w historii z precyzją

git log jest bardziej elastyczny niż prosta lista commitów, ponieważ pozwala zawężać historię po autorze, czasie, pliku, opisie albo nawet po fragmencie kodu.

git log --oneline --graph --decorate --all
git log --author="Jan"
git log --since="1 week ago"
git log -- path/to/file.ts
git log --grep="fix validation"
git log -S "validateEmail"
git log -G "validate[A-Za-z]+"
git log -p
git log --stat

Najbardziej praktyczne warianty:

• git log --graph --decorate --oneline --all pokazuje rozjazd branchy w czytelnej formie.
• git log -- path/to/file.ts zawęża historię do jednego pliku.
• git log -S "nazwaFunkcji" szuka commitów zmieniających liczbę wystąpień dokładnego tekstu.
• git log -G "wyrażenie" szuka diffów, których dodane lub usunięte linie pasują do wyrażenia regularnego.
• git log -p pokazuje diff każdego commita.

Jeśli debugujesz zmianę zachowania aplikacji, połącz git log -S z testami i narzędziami diagnostycznymi właściwymi dla aplikacji.

8. git diff: zobacz, co naprawdę się zmieniło

git diff pokazuje różnice między working directory, staging area, commitami i branchami. To komenda, którą warto uruchamiać przed commitem częściej niż po fakcie.

git diff
git diff --staged
git diff main..feature/login
git diff main...feature/login
git diff HEAD~1 HEAD
git diff --name-only
git diff -w

Dwie i trzy kropki odpowiadają na inne pytania. main..feature/login porównuje końcowe drzewa obu commitów, a main...feature/login porównuje feature z punktem wspólnego przodka, co zwykle lepiej odpowiada zmianom widocznym w pull requeście.

Najczęstszy workflow przed commitem:

git status --short
git diff
git diff --staged

git diff chroni przed przypadkowym dorzuceniem debug logów, lokalnych zmian konfiguracyjnych albo fragmentu pracy z innego zadania. To szczególnie ważne, gdy pracujesz na dużym branchu i staging robisz partiami.

9. git clean: jak usunąć nieśledzone pliki?

git clean usuwa pliki, których Git nie śledzi. To przydatne po eksperymentach, buildach, generowanych plikach albo zmianach zależności, ale jest też jedną z bardziej ryzykownych komend z tej listy.

git clean -n
git clean -nd
git clean -ndx
git clean -f
git clean -fd
git clean -fdx
git clean -i

Różnice są istotne:

git clean usuwa pliki, których Git z definicji nie śledzi. Po wykonaniu operacji reflog zwykle nie ma czego odzyskiwać. Pozostają historia lokalna edytora, snapshot systemu plików, kosz systemowy lub backup, dlatego dokładny dry run jest tu ważniejszy niż przy operacjach na commitach.

Jeśli nie masz pewności, użyj git clean -i. Tryb interaktywny jest wolniejszy, ale daje dodatkową kontrolę nad tym, co faktycznie zniknie.

10. git worktree: kilka branchy bez ciągłego przełączania

git worktree pozwala mieć kilka katalogów roboczych podpiętych do tego samego repozytorium. Każdy katalog może pracować na innym branchu.

# Wariant A: podepnij istniejący branch
git worktree add ../project-hotfix hotfix/payment-error
 
# Wariant B: utwórz nowy branch od main
git worktree add -b hotfix/payment-error ../project-hotfix main
 
git worktree list
git worktree remove ../project-hotfix

Pierwsze dwie komendy są wariantami, nie sekwencją do wykonania jedna po drugiej. Git nie pozwala zwykle podpiąć tego samego brancha do dwóch worktree jednocześnie, co chroni przed równoległą edycją tej samej linii pracy w kilku katalogach.

To rozwiązuje typowy problem. Wyobraź sobie sytuację: jesteś w połowie większej zmiany, a nagle trzeba zrobić review albo hotfix. Bez worktree kończy się to stashowaniem, przełączaniem brancha i późniejszym odtwarzaniem kontekstu. Z worktree otwierasz drugi katalog i pracujesz równolegle.

Ratunkowe scenariusze Git krok po kroku

Poniższe przykłady to skrót decyzyjny — zakładają, że przed wykonaniem komendy sprawdzasz stan repozytorium przez git status.

Jak przerwać niedokończony merge, rebase albo cherry-pick?

Nie zgaduj, która operacja trwa. git status pokaże stan sekwencera i właściwą komendę. Jeżeli chcesz wrócić do punktu sprzed rozpoczęcia operacji, użyj odpowiadającego jej --abort:

git merge --abort
git rebase --abort
git cherry-pick --abort
git revert --abort

Uruchom tylko komendę pasującą do bieżącej operacji. --quit ma inne znaczenie: zapomina stan sekwencera, ale nie musi odtworzyć indexu i working tree, dlatego nie jest zamiennikiem --abort.

Jak cofnąć ostatni lokalny commit, ale zostawić zmiany?

git reset --soft HEAD~1

Użyj tego, gdy commit jest lokalny i chcesz poprawić treść commita, dodać brakujący plik albo inaczej podzielić zmiany.

Co zrobić po commicie na złym branchu?

Jeśli commit jest ostatni, nie został wypchnięty, a working tree jest czysty, najpierw utwórz poprawny branch wskazujący ten commit, a dopiero później przesuń branch błędny:

# Będąc nadal na błędnym branchu:
git branch correct-branch HEAD
git reset --hard HEAD~1
 
# Dopiero teraz przejdź do uratowanego commita
git switch correct-branch

Branch correct-branch zabezpiecza commit przed resetem. Jeśli na working tree są dodatkowe zmiany, najpierw je skopiuj lub zapisz, zamiast wykonywać --hard. Gdy commit trafił już na współdzielony remote, bezpieczniejszy wariant to git revert na złym branchu i git cherry-pick na właściwym.

Jak zmienić opis ostatniego commita?

git commit --amend -m "Poprawny opis commita"

amend zmienia hash commita. Lokalnie to normalne narzędzie. Na własnym branchu po pushu uzgodnij przepisanie historii i użyj ochrony --force-with-lease; na branchu współdzielonym dodaj kolejny commit zamiast nadpisywać istniejący.

Jak dodać plik do ostatniego commita?

git add forgotten-file.ts
git commit --amend --no-edit

To dobre rozwiązanie, gdy commit nie został jeszcze wypchnięty albo pracujesz na prywatnym branchu.

Jak cofnąć zmianę wypchniętą na remote?

git revert HEAD
git push

To najczytelniejsza ścieżka na branchach współdzielonych. Historia pokazuje zarówno pierwotną zmianę, jak i commit cofający.

Jak cofnąć merge commit?

git revert -m 1 HEAD

-m 1 wskazuje pierwszego rodzica jako główną linię historii, ale nie każdy merge należy cofać względem rodzica numer 1. Najpierw sprawdź rodziców przez git show --no-patch --pretty=%P HEAD i potwierdź właściwą linię. Cofnięcie merge commita wpływa również na zachowanie przyszłych scaleń, dlatego w złożonym przypadku przećwicz operację na branchu testowym.

Jak odzyskać usunięty śledzony plik?

Jeżeli usunięcie nie trafiło do staging area, przywróć wersję z indexu:

git restore -- path/to/file.ts

Jeżeli usunięcie zostało już dodane do staging area, najpierw odtwórz wpis indexu z HEAD, a następnie plik roboczy:

git restore --staged -- path/to/file.ts
git restore -- path/to/file.ts

Jeśli chcesz pobrać wersję z określonego commita, wskaż źródło jawnie:

git restore --source abc1234 -- path/to/file.ts

Komendy zapisujące do working tree mogą nadpisać lokalną wersję pliku. Przed wykonaniem sprawdź git diff -- path/to/file.ts, aby nie usunąć innych zmian w tym samym miejscu.

Jak pobrać jeden plik z innego brancha?

git restore --source other-branch -- path/to/file.ts

To czytelniejsza, nowocześniejsza alternatywa dla starszych wariantów opartych o git checkout --.

Kiedy wolno użyć push --force-with-lease?

Po rebase lub amend na własnym branchu pull requesta zwykły push nie jest fast-forward. --force-with-lease odmawia nadpisania, jeśli zdalna referencja nie ma oczekiwanej wartości, dlatego jest bezpieczniejsze od --force, ale nie stanowi blokady absolutnej. Automatyczny fetch może zaktualizować remote-tracking branch i osłabić domyślną kontrolę.

git fetch origin
git log --oneline --left-right origin/my-branch...my-branch
git push --force-with-lease origin my-branch

Nie stosuj tego mechanizmu do main ani brancha współdzielonego bez jawnego uzgodnienia i ochrony po stronie serwera.

Jak sprawdzić, kto zmienił konkretną linię?

git blame path/to/file.ts
git blame -L 10,20 path/to/file.ts

Wbrew nazwie git blame nie służy do szukania winnych — najlepiej traktować go jako narzędzie do znalezienia kontekstu: commita, pull requesta, decyzji technicznej albo osoby, którą warto zapytać o szczegóły.

Git cheat sheet: którą komendę wybrać?

Na koniec krótka, praktyczna ściągawka.