Jak Cofnac Commit w Git? 5 Bezpiecznych Sposobow: Reset, Revert, Restore (Poradnik 2026)

Kazdy, kto pracuje z systemem kontroli wersji Git, wie, ze pomylki sa nieuniknione. Zdarza sie zacommitowac cos, czego nie powinno byc w projekcie, zle scalic galezie, czy przypadkowo usunac wazny fragment kodu. Bez opanowania sztuki cofania zmian, zarzadzanie repozytorium moze stac sie prawdziwym koszmarem, zagrazajacym stabilnosci projektu i terminowosci dostarczenia kluczowych elementow.

Na szczescie Git oferuje szereg potezncyh narzedzi, ktore pozwalaja naprawic niemal kazdy blad. Kluczem jest jednak zrozumienie, jak dzialaja te mechanizmy i kiedy zastosowac odpowiednia komende, aby nie pogorszyc sytuacji. Niewlasciwe uzycie komendy git reset -hard moze prowadzic do nieodwracalnej utraty pracy, szczegolnie jesli zmiany zostaly juz wypchniete do zdalnego repozytorium. Zgodnie z oficjalna dokumentacja Git, kazdy z trybow reset ma inny wplyw na katalog roboczy, indeks i historie.

Szybki wybor: reset czy revert? (i kiedy checkout/restore)

Jesli spieszysz sie i potrzebujesz natychmiastowej odpowiedzi, oto najwazniejsza zasada w cofaniu zmian w Git - wybor zalezy wylacznie od tego, czy commit zostal juz wypchniety (git push) do wspoldzielonego repozytorium:

Sytuacja	Uzyj	Dlaczego
Commit tylko lokalny, jeszcze nie wypchniety	git reset	Mozesz bezpiecznie nadpisac lokalna historie, nikt inny jej nie ma.
Commit juz wypchniety, inni moga go miec pobranego	git revert	Tworzy nowy commit odwracajacy zmiany, nie nadpisuje wspoldzielonej historii.
Chcesz cofnac zmiany w jednym pliku, bez commita	git restore nazwa-pliku	Nowoczesny odpowiednik git checkout - plik, dedykowany wylacznie do przywracania plikow.
Commit zniknal po pomylce z reset -hard	git reflog + git reset -hard hash	Reflog przechowuje historie wszystkich ruchow HEAD, nawet tych „usunietych”.

Ta jedna zasada - lokalny commit vs juz wypchniety commit - rozstrzyga wiekszosc watpliwosci w praktyce. Ponizej znajdziesz pelne wyjasnienie kazdej z tych komend, dokladne scenariusze krok po kroku oraz aktualne przyklady polecen, wlacznie z nowoczesnymi git restore i git switch.

Co znajdziesz w tym artykule:

• Szybki wybor: reset czy revert?
• Fundamenty cofania zmian: stany repozytorium
• Reset, revert, checkout: dogłebne porownanie
• Git restore i git switch: nowoczesne podejscie od wersji 2.23
• Praktyczny poradnik: cofanie zmian krok po kroku
• Git stash i commit -amend: szybkie techniki ratunkowe
• Najczestsze bledy przy cofaniu zmian i jak ich unikac
• Cofanie zmian z poziomu edytora: VS Code, GitKraken, GitHub Desktop
• Najczesciej zadawane pytania (FAQ)

Fundamenty cofania zmian: zrozumienie stanow repozytorium

Zanim zaglebimy sie w konkretne komendy, kluczowe jest zrozumienie, jak Git zarzadza plikami i historia projektu. Git to rozproszony system kontroli wersji, co oznacza, ze kazdy deweloper posiada pelna kopie historii projektu na swoim lokalnym komputerze. Centralnym elementem Git jest commit - migawka projektu w danym momencie, zawierajaca wszystkie zmiany od poprzedniego commita. Zrozumienie tego procesu jest wazne dla kazdego, kto zajmuje sie tworzeniem stron internetowych czy ogolnie praca w IT.

Git operuje na trzech glownych obszarach plikow, ktore nalezy rozroznic przy cofaniu zmian:

• Katalog roboczy (Working Directory): miejsce, gdzie faktycznie modyfikujesz pliki. Widzisz tu aktualna wersje projektu, z naniesionymi zmianami, ktore jeszcze nie zostaly dodane do systemu kontroli wersji.
• Indeks (Staging Area): bufor miedzy katalogiem roboczym a repozytorium. Tutaj przygotowujesz zmiany, ktore chcesz wlaczyc do nastepnego commita.
• Repozytorium (Repository): wlasciwa baza danych Git, w ktorej przechowywana jest cala historia projektu w postaci commitow. Zmiany z indeksu sa do niego dodawane komenda git commit.

Kazda komenda do cofania zmian wplywa na te obszary w inny sposob, co ma kluczowe znaczenie dla bezpieczenstwa i efektywnosci Twojej pracy. Znajomosc tych fundamentow pozwoli Ci swiadomie podejmowac decyzje, zwlaszcza jesli chcesz utrzymac czysta historie projektu, co jest istotne przy profesjonalnym projektowaniu stron. Wiecej o wewnetrznej budowie repozytorium (obiekty blob, tree i commit) znajdziesz w rozdziale Git Internals w oficjalnym Pro Git book.

Reset, revert, checkout: dogłebne porownanie metod cofania zmian w Git

Trzy najczesciej uzywane komendy do cofania zmian w Git to git reset, git revert i git checkout. Choc wszystkie sluza do „cofania”, kazda z nich dziala na zupelnie innej zasadzie i jest przeznaczona do innych scenariuszy. Niewlasciwy wybor moze prowadzic do niechcianych konsekwencji, takich jak utrata historii czy nadpisanie pracy innych czlonkow zespolu.

1. git reset - nadpisywanie historii (uzywac ostroznie)

Komenda git reset sluzy do resetowania biezacej galezi (HEAD) do okreslonego stanu. Ma trzy glowne tryby dzialania:

• git reset -soft commit_hash: przenosi HEAD do wskazanego commita, ale pozostawia zmiany z „cofnietych” commitow w indeksie. Pozwala na ponowne zacommitowanie tych zmian jako jeden nowy commit.
• git reset -mixed commit_hash (domyslny): przenosi HEAD do wskazanego commita i przenosi zmiany do katalogu roboczego (unstaged), usuwajac je z indeksu.
• git reset -hard commit_hash: najbardziej destrukcyjny tryb. Nadpisuje zarowno indeks, jak i katalog roboczy, usuwajac wszelkie niezacommitowane zmiany i „cofniete” commity bezpowrotnie z lokalnego stanu.

Przyklad: aby sprawdzic historie i cofnac ostatni commit razem ze wszystkimi jego zmianami, uzyj kolejno git log -oneline, a nastepnie git reset -hard HEAD~1.

2. git revert - bezpieczne cofanie przez nowy commit

Git revert dziala na zupelnie innej zasadzie niz git reset. Zamiast usuwac commity z historii, tworzy nowy commit, ktory wprowadza zmiany dokladnie odwrotne do zmian wprowadzonych przez wskazany commit. Oryginalny commit pozostaje w historii projektu. Jest to preferowana metoda cofania zmian w publicznych lub wspoldzielonych repozytoriach. Dobra praktyke jej stosowania opisuje rowniez tutorial Atlassian o cofaniu zmian w Git. Przyklad: git log -oneline, aby znalezc hash commita, a nastepnie git revert commit_hash, aby utworzyc nowy commit cofajacy.

3. git checkout - przywracanie stanu plikow lub galezi

Komenda git checkout jest przede wszystkim uzywana do przelaczania sie miedzy galeziami lub do przywracania stanu pojedynczych plikow. Warto wiedziec, ze git checkout ma dwie zupelnie rozne funkcje (przelaczanie galezi i przywracanie plikow) polaczone w jednej komendzie, co bywa mylace i doprowadzilo do wprowadzenia nowych, bardziej precyzyjnych komend opisanych w kolejnej sekcji. Przyklad przywrocenia pliku: git checkout - nazwa-pliku cofa zmiany w pliku do stanu ostatniego commita.

Cecha	git reset	git revert	git checkout
Modyfikacja historii	Tak (nadpisuje historie)	Nie (tworzy nowy commit)	Nie (przelacza stan plikow/galezi)
Wplyw na repozytorium zdalne	Moze wymagac git push -force, co jest ryzykowne w zespolach.	Bezpieczny do pushowania, nie powoduje konfliktow historii.	Nie wplywa bezposrednio na historie, tylko na lokalny stan.
Scenariusze uzycia	Cofanie zmian lokalnie, przed wypchnieciem. Poprawianie bledow w prywatnej galezi.	Cofanie zmian w publicznych/wspoldzielonych repozytoriach. Anulowanie blednych commitow po pushu.	Przywracanie pojedynczych plikow do wczesniejszego stanu. Przelaczanie galezi.
Ryzyko utraty danych	Wysokie (szczegolnie -hard), jesli nie wiesz, co robisz.	Niskie, wszystkie zmiany sa zapisane w historii.	Niskie, jesli rozumiesz, ze zmiany sa nadpisywane lokalnie.

Podsumowujac, wybor miedzy git reset, git revert a git checkout zalezy od kontekstu i Twoich intencji. Jesli pracujesz lokalnie i chcesz calkowicie usunac historie, git reset moze byc uzyteczny. Jednakze, jesli pracujesz w zespole i zmiany zostaly juz udostepnione, git revert jest znacznie bezpieczniejsza opcja. Bezpieczenstwo i stabilnosc projektu to aspekty, na ktore stawiamy w Studio Kalmus oferujac strony internetowe w Piasecznie i okolicach.

Git restore i git switch: nowoczesne podejscie od wersji 2.23

Od wersji 2.23 Git wprowadzil dwie nowe komendy, ktore rozwiazuja problem „przeciazenia” git checkout zbyt wieloma odpowiedzialnosciami. Git switch sluzy wylacznie do przelaczania sie miedzy galeziami, a git restore wylacznie do przywracania plikow - czy to w katalogu roboczym, czy w indeksie. Szczegoly obu komend znajdziesz w oficjalnej dokumentacji git-restore.

• git restore nazwa-pliku - cofa zmiany w pliku w katalogu roboczym (odpowiednik git checkout - plik).
• git restore -staged nazwa-pliku - wyjmuje plik z indeksu (odpowiednik git reset HEAD - plik), zachowujac zmiany w katalogu roboczym.
• git restore -source=commit_hash nazwa-pliku - przywraca plik do stanu z konkretnego commita.
• git switch nazwa-galezi - przelacza galaz (odpowiednik git checkout nazwa-galezi).
• git switch -c nowa-galaz - tworzy i przelacza na nowa galaz w jednym kroku.

Praktyczna rada: jesli pracujesz na nowszej wersji Gita (sprawdzisz to komenda git -version), warto przyzwyczaic sie do git restore i git switch zamiast git checkout przy nowych projektach. Stary git checkout nadal dziala i nigdzie nie zniknie, wiec nie musisz w panice przepisywac istniejacych skryptow czy dokumentacji zespolowej - ale nowe komendy sa czytelniejsze i bezpieczniejsze dla osob dopiero uczacych sie Git, co ma znaczenie takze przy onboardingu nowych programistow w zespole tworzacym sklepy internetowe czy inne rozbudowane aplikacje webowe.

Praktyczny poradnik: cofanie zmian w konkretnych scenariuszach Git (krok po kroku)

Teoria jest wazna, ale w praktyce najczesciej spotykamy sie z konkretnymi scenariuszami, ktore wymagaja szybkiego i efektywnego dzialania. Oto najpopularniejsze sytuacje, w ktorych mozesz potrzebowac cofnac zmiany w Git, wraz z instrukcjami krok po kroku i rekomendowanymi komendami.

1. Cofniecie ostatniego commita (lokalnie, przed pushowaniem)

To najczestszy scenariusz. Zacommitowales cos, ale od razu zdales sobie sprawe z bledu i nie zdazyles wypchnac zmian na zdalne repozytorium. W tej sytuacji git reset jest idealny.

• Cofnij commit i zachowaj zmiany w katalogu roboczym (do dalszej edycji): git reset HEAD~1 (lub pelny zapis git reset -mixed HEAD~1). HEAD~1 oznacza commit poprzedzajacy aktualny HEAD.
• Cofnij commit i zachowaj zmiany w indeksie (gotowe do ponownego commita): git reset -soft HEAD~1. Zmiany pozostana w indeksie, a Ty bedziesz mogl je edytowac lub od razu stworzyc nowy commit.
• Calkowicie usun ostatni commit i wszystkie jego zmiany: git reset -hard HEAD~1. Ostrzezenie: uzywaj tego z rozwaga, stracisz wszystkie zmiany wprowadzone w ostatnim commicie.

2. Cofniecie wielu commitow (lokalnie, przed pushowaniem)

Jesli chcesz cofnac kilka ostatnich commitow, uzyj podobnych komend, wskazujac odpowiedni commit lub liczbe commitow do cofniecia.

• Cofnij ostatnie 3 commity, zachowujac zmiany w indeksie: git reset -soft HEAD~3.
• Cofnij ostatnie 3 commity, zachowujac zmiany w katalogu roboczym: git reset -mixed HEAD~3.
• Usun wszystkie zmiany z 3 ostatnich commitow bezpowrotnie: git reset -hard HEAD~3.
• Cofnij do konkretnego commita, np. o hashu abcdef12: git reset -hard abcdef12. Wszystkie commity po abcdef12 zostana usuniete z lokalnej historii.
• Usun tylko jeden, konkretny commit ze srodka historii: uzyj interaktywnego rebase komenda git rebase -i HEAD~5. W otwartym edytorze zmien pick na drop przy commicie, ktory chcesz odrzucic, zapisz plik, a Git odtworzy pozostale commity bez niego.

3. Cofniecie zmian w konkretnym pliku (przed commitem)

Jesli zmodyfikowales plik i chcesz przywrocic go do stanu z ostatniego commita (porzucajac lokalne zmiany), uzyj git checkout - nazwa-pliku, albo nowoczesniej git restore nazwa-pliku. Komenda usunie wszelkie niezapisane zmiany w pliku i przywroci jego wersje z HEAD.

4. Cofniecie niechcianego git push (po wypchnieciu do zdalnego repozytorium)

To scenariusz, ktory wymaga najwiekszej ostroznosci, poniewaz wplywa na wspolna historie. Zazwyczaj preferowanym rozwiazaniem jest git revert.

• Bezpieczna metoda (rekomendowana dla repozytoriow wspoldzielonych): git revert commit_hash, aby utworzyc nowy commit cofajacy zmiany, a nastepnie git push origin nazwa-galezi, aby go wypchnac. Inni deweloperzy moga bez problemu pobrac zmiany.
• Destrukcyjna metoda (tylko w skrajnych przypadkach, wylacznie na prywatnej galezi): jesli musisz calkowicie usunac commity ze zdalnego repozytorium (np. przypadkowo wyslales dane uwierzytelniajace), uzyj git reset -hard HEAD~1, a nastepnie git push -force origin nazwa-galezi. Nigdy nie uzywaj -force na galeziach, na ktorych pracuja inni, chyba ze jestes absolutnie pewien, ze nikt inny nie pobral tych commitow. Bezpieczniejsza alternatywa jest git push -force-with-lease, ktora odmowi wykonania, jesli ktos inny w miedzyczasie wypchnal nowe commity.

5. Przywracanie „utraconych” commitow za pomoca git reflog

Jesli przypadkowo uzyles git reset -hard i stracles commity, nie wszystko stracone. Git zachowuje logi wszystkich operacji HEAD w tzw. reflogu.

• Sprawdz reflog: git reflog. Zobaczysz liste wszystkich operacji, ktore modyfikowaly HEAD, wraz z hashami commitow.
• Przywroc stan: znajdz hash commita, do ktorego chcesz wrocic (np. b1a2c3d) i uzyj git reset -hard b1a2c3d, aby przywrocic repozytorium do stanu tego commita.

Git reflog jest prawdziwym kolem ratunkowym w krytycznych sytuacjach, dziala jednak wylacznie lokalnie i nie jest czescia repozytorium udostepnianego innym.

Git stash i commit -amend: szybkie techniki ratunkowe

Oprocz klasycznego cofania zmian, w codziennej pracy przydaja sie dwie dodatkowe komendy, ktore czesto ratuja sytuacje, zanim w ogole dojdzie do potrzeby uzycia reset czy revert.

1. git stash - tymczasowe odlozenie zmian na bok

Jesli pracujesz nad czyms, a nagle musisz przelaczyc sie na inna galaz (np. do pilnej poprawki), ale nie chcesz jeszcze commitowac niedokonczonych zmian, git stash pozwala je „schowac” i wrocic do nich pozniej.

• git stash - chowa biezace, niezacommitowane zmiany.
• git stash list - pokazuje liste schowanych zmian.
• git stash pop - przywraca ostatnio schowane zmiany i usuwa je ze stosu.
• git stash apply - przywraca zmiany, ale zachowuje je rowniez na stosie stash.

2. git commit -amend - poprawianie ostatniego commita bez tworzenia nowego

Jesli zauwazyles literowke w tresci ostatniego commita albo zapomniales dodac jeden plik, nie musisz robic nowego commita. Git commit -amend pozwala dolaczyc zmiany do ostatniego commita lub poprawic jego opis.

• Dodaj zapomniany plik, zachowujac te sama wiadomosc: git add zapomniany-plik.txt, a nastepnie git commit -amend -no-edit.
• Popraw tylko wiadomosc ostatniego commita: git commit -amend -m „Poprawiona, czytelna wiadomosc commita”.

Wazna uwaga bezpieczenstwa: zarowno git commit -amend, jak i interaktywny rebase z sekcji powyzej, modyfikuja historie commitow - podobnie jak git reset -hard. Uzywaj ich swobodnie na commitach, ktorych jeszcze nie wypchnales do zdalnego repozytorium. Jesli commit zostal juz wypchniety i inni moga go miec pobranego, poprawianie go wymaga git push -force (lub bezpieczniejszego -force-with-lease) i powinno byc uzgodnione z zespolem.

Opanowanie tych technik to klucz do efektywnej i bezstresowej pracy z Git. W Studio Kalmus rozumiemy, ze sprawne zarzadzanie kodem to podstawa sukcesu kazdego projektu, od malych stron OnePage po skomplikowane systemy. Dlatego podczas gdy Ty skupiasz sie na doskonaleniu swoich umiejetnosci w Git, my mozemy zajac sie tworzeniem profesjonalnych stron internetowych, ktore beda dzialac bez zarzutu i przyciagac klientow, niezaleznie od tego, czy szukasz uslug reklamowych, czy kompleksowego pozycjonowania stron internetowych.

Najczestsze bledy przy cofaniu zmian w Git i jak ich unikac

Nawet doswiadczeni programisci popelniaja te same bledy przy cofaniu zmian w Git. Ponizsza lista opisuje sytuacje, ktore najczesciej prowadza do utraty pracy lub konfliktow w zespole, wraz z konkretnym sposobem, jak sie przed nimi zabezpieczyc.

Blad	Skutek	Jak sie zabezpieczyc
Uzycie git reset -hard bez sprawdzenia git status	Utrata niezacommitowanych zmian w katalogu roboczym, bez mozliwosci odzyskania przez reflog.	Zawsze uruchom git status i git diff przed -hard, ewentualnie zrob git stash na wszelki wypadek.
git push -force na galezi wspoldzielonej przez zespol	Koledzy traca lokalne commity oparte na nadpisanej historii, powstaja trudne do rozwiazania konflikty.	Uzywaj git push -force-with-lease i ustal z zespolem zasady pracy na wspolnych galeziach.
Mylenie git revert z git reset przy juz wypchnietym commicie	Proba nadpisania historii, ktora inni juz pobrali, prowadzi do konfliktow przy kolejnym pull.	Zapamietaj regule z sekcji „Szybki wybor”: jesli commit jest juz na zdalnym repozytorium, uzyj revert, nie reset.
Zaufanie, ze reflog dziala wiecznie	Wpisy w reflogu domyslnie wygasaja po 90 dniach (nieosiagalne commity) lub 30 dniach dla nieosiagalnych referencji, wiec stary blad moze byc juz nie do odzyskania.	Odzyskuj utracone commity mozliwie szybko, nie odkladaj tego na pozniej.
Cofanie zmian bez uprzedniego commita lub stash	Przypadkowe nadpisanie kilku godzin pracy jednym poleceniem checkout/restore.	Zanim wykonasz cofniecie, zrob szybki git stash lub commit „wip” - zawsze mozna go pozniej scalic lub usunac.

Dobra praktyka defensywna, ktora oszczedza wiele stresu: przed kazda operacja opisana w tym poradniku jako „destrukcyjna” wykonaj git branch kopia-bezpieczenstwa, aby oznaczyc biezacy stan HEAD dodatkowa galezia. Jesli cos pojdzie nie tak, wracasz do niej jednym git switch, bez polegania wylacznie na reflogu. To szczegolnie wazne przy wiekszych refaktoryzacjach, gdzie stawka bledu jest wyzsza, np. przy pracach nad wydajnoscia czy pozycjonowaniem strony, gdzie zmiany w kodzie czesto wplywaja bezposrednio na wyniki wyszukiwania.

Cofanie zmian z poziomu edytora: VS Code, GitKraken, GitHub Desktop

Wiekszosc opisanych wyzej komend mozna wykonac rowniez z poziomu graficznego interfejsu, co bywa wygodniejsze dla osob, ktore wola widziec historie commitow w formie wizualnej zamiast tekstowej.

• Visual Studio Code: w zakladce Source Control klikniecie prawym przyciskiem na commit w widoku Timeline daje opcje „Revert Commit” (odpowiednik git revert). Rozszerzenie GitLens dodatkowo pozwala przegladac historie zmian linia po linii i przywracac pojedyncze fragmenty pliku bez dotykania konsoli.
• GitKraken: graficzny graf commitow pozwala przeciagnac HEAD do wybranego commita (odpowiednik reset), kliknac prawym przyciskiem „Revert commit” albo przywrocic pojedynczy plik z dowolnego punktu historii przez podglad w panelu bocznym.
• GitHub Desktop: prostszy klient, w ktorym historia commitow ma opcje „Revert this commit” bezposrednio z menu kontekstowego, a niezacommitowane zmiany w plikach mozna odrzucic (discard) jednym klikniciem, co odpowiada git restore.

Warto jednak pamietac, ze narzedzia graficzne w tle wywoluja te same komendy Gita opisane w tym poradniku - rozumienie mechanizmu reset/revert/restore pozwala swiadomie interpretowac to, co robi klikniecie w interfejsie, zamiast polegac na „magii” edytora. To zwlaszcza wazne przy wiekszych zespolach programistycznych, gdzie mieszaja sie preferencje co do narzedzi, a spojne zrozumienie fundamentow Gita zapobiega nieporozumieniom niezaleznie od tego, kto jakiego klienta uzywa.

Najczesciej zadawane pytania (FAQ)

Ponizej znajdziesz odpowiedzi na pytania, ktore najczesciej pojawiaja sie przy cofaniu zmian w Git - od podstawowej roznicy miedzy reset a revert, po szczegoly dotyczace reflogu i restore.

Jaka jest fundamentalna roznica miedzy git reset -hard a git revert?

Fundamentalna roznica lezy w sposobie modyfikacji historii i wplywie na repozytorium zdalne. Git reset -hard nadpisuje historie, usuwajac commity i wszystkie zwiazane z nimi zmiany z lokalnego repozytorium, indeksu i katalogu roboczego. Jest destrukcyjny i powinien byc uzywany tylko lokalnie lub w prywatnych galeziach, nigdy w udostepnionych, poniewaz wymagalby git push -force. Git revert tworzy nowy commit, ktory cofa zmiany z wybranego commita, a oryginalny commit pozostaje w historii - jest to bezpieczna opcja dla repozytoriow wspoldzielonych.

Czy moge cofnac git push? Jesli tak, to jak?

Tak, mozesz „cofnac” git push, ale metoda zalezy od tego, czy pracujesz w repozytorium prywatnym, czy wspoldzielonym. W repozytorium wspoldzielonym uzyj git revert - utworz nowy commit, ktory cofa zmiany z blednego commita, a nastepnie wypchnij ten nowy commit. W repozytorium prywatnym mozesz uzyc git reset -hard lokalnie, a nastepnie git push -force (lub bezpieczniejsze -force-with-lease) do zdalnego repozytorium, choc jest to ryzykowne w srodowisku zespolowym.

Jak moge odzyskac commit, ktory zniknal po uzyciu git reset -hard?

Jesli przypadkowo usunales commity za pomoca git reset -hard, mozesz je odzyskac uzywajac komendy git reflog, ktora pokazuje dziennik wszystkich operacji na HEAD. Znajdz hash commita, do ktorego chcesz wrocic w liscie reflogu (oznaczony jako HEAD@{numer}), a nastepnie uzyj git reset -hard z tym hashem, aby przywrocic repozytorium do stanu tego commita. Reflog jest lokalny i dziala tylko na Twoim komputerze.

Czym rozni sie git restore od git checkout?

Git restore to nowsza komenda (od Git 2.23), ktora przejela z git checkout wylacznie odpowiedzialnosc za przywracanie plikow - w katalogu roboczym lub w indeksie. Do przelaczania galezi sluzy z kolei osobna komenda git switch. Stary git checkout nadal dziala identycznie jak wczesniej i nie zostal usuniety, ale nowe komendy sa zalecane w dokumentacji Git jako czytelniejsze dla nowych projektow.

Jak cofnac zmiany tylko z jednego pliku, nie ruszajac reszty zmian w commicie?

Jesli plik jest juz w indeksie (po git add), ale chcesz wycofac z niego zmiany przed commitem, uzyj git restore -staged nazwa-pliku, aby wyjac go z indeksu, a nastepnie git restore nazwa-pliku, aby przywrocic jego zawartosc do stanu z ostatniego commita. Reszta zmian w innych plikach pozostanie nietknieta.

Kiedy uzyc reset -soft, a kiedy -mixed?

Uzyj -soft, gdy chcesz od razu miec cofniete zmiany gotowe do ponownego zacommitowania bez dodatkowego git add - trafiaja prosto do indeksu. Uzyj -mixed (domyslny tryb reset bez flagi), gdy chcesz najpierw przejrzec lub zedytowac cofniete zmiany w katalogu roboczym, zanim zdecydujesz, co dokladnie trafi do nastepnego commita - to najczestszy wybor przy poprawianiu pojedynczego, niedokonczonego commita.

Czy git reset usuwa commity na zawsze?

Nie natychmiast. Commity „usuniete” przez git reset -hard nie znikaja od razu z bazy danych Gita - staja sie nieosiagalne z zadnej galezi, ale wciaz istnieja fizycznie i mozna je odzyskac przez git reflog, dopoki nie zostana usuniete przez wewnetrzny garbage collector (domyslnie po okolo 30-90 dniach, w zaleznosci od typu wpisu). Traktuj to jednak jako siatke bezpieczenstwa na krotki czas, a nie trwale archiwum.

Jak cofnac zmiany w Git bez utraty historii commitow, gdy blad zauwazono po tygodniu?

Jesli blad znajduje sie w commicie sprzed kilku dni, a od tego czasu powstalo wiele nowych commitow, najbezpieczniejszym rozwiazaniem jest git revert z konkretnym hashem tego starszego commita - Git automatycznie utworzy nowy commit odwracajacy tylko te zmiany, nie ruszajac niczego, co powstalo pozniej. Jesli zmieniane linie nachodza na siebie z pozniejszymi commitami, Git poprosi o reczne rozwiazanie konfliktu, podobnie jak przy zwyklym merge.