Do tej pory rozważaliśmy idealny scenariusz: piszesz kod, robisz commity, tworzysz Pull Request. Ale w rzeczywistości często coś idzie nie tak: możesz popełnić błąd w kodzie, zrobić commit z niepoprawnym komunikatem albo po prostu zorientować się, że poszedłeś w złą stronę. W tej lekcji przeanalizujemy, jak rozwiązywać najczęstsze problemy.
1. Rollback — cofanie zmian przed commitem
Scenariusz: zmodyfikowałeś plik, ale zrozumiałeś, że wszystkie twoje poprawki są nieprawidłowe i chcesz szybko przywrócić plik do stanu, w którym był po ostatnim commicie.
Użyj funkcji Rollback:
- Otwórz zakładkę
Commit. - Znajdź na liście zmodyfikowany plik, który chcesz "cofnąć".
- Kliknij na niego prawym przyciskiem myszy i wybierz
Rollback.
IDE ostrzeże cię, że zmiany zostaną utracone. Potwierdź, a plik natychmiast wróci do swojej ostatniej wersji zapisanej w Git. To najprostszy i najbezpieczniejszy sposób na cofnięcie lokalnych zmian.
2. Reset — usuwanie lokalnych commitów
Scenariusz: zrobiłeś jeden lub kilka commitów, ale jeszcze nie wykonałeś push. Zrozumiałeś, że te commity są błędne i chcesz je całkowicie usunąć, jakby ich w ogóle nie było.
Użyj funkcji Reset:
- Otwórz zakładkę
Git -> Log, aby zobaczyć historię commitów. - Znajdź ostatni "dobry" commit, na którym chcesz się znaleźć (ten, który był przed błędnymi).
- Kliknij na niego prawym przyciskiem myszy i wybierz
Reset Current Branch to Here....
W otwartym oknie zaproponują ci wybór trybu resetu. Najbardziej radykalny to Hard.
Uwaga! Tryb Hard bezpowrotnie usuwa wszystkie commity po wybranym, oraz wszystkie zmiany w kodzie, które były w tych commitach. Używaj go z dużą ostrożnością i tylko dla commitów, które jeszcze nikt nie widział (tych, które nie były wysłane na GitHub).
3. Co robić po Push?
Scenariusz: wykonałeś push, a dopiero potem zauważyłeś w nim błąd.
Gdy commit trafi na zdalny serwer, staje się częścią wspólnej historii projektu. Próba przepisywania tej historii może spowodować ogromne problemy dla twoich kolegów. Wyobraź sobie, że już pobrali twoje zmiany i zaczęli pracować na ich podstawie.
Prawidłowe i bezpieczne rozwiązanie:
Po prostu zrób nowy commit, który naprawia błąd, i wyślij go. To całkowicie normalna praktyka. W ten sposób historia pozostaje uczciwa i zrozumiała dla wszystkich.
4. Zajrzeć w przeszłość: zaawansowana praca z logiem
Już znamy zakładkę Git -> Log, ale to nie tylko lista commitów, to potężne narzędzie do śledztw.
- Hash commita (Commit Hash): na pewno zauważyłeś w logu ciąg liter i cyfr, na przykład
a1b2c3d. Ten hash jest unikalny i pozwala dokładnie odwołać się do dowolnego punktu w historii projektu. Rzadko będziesz musiał używać go ręcznie, ale warto wiedzieć, że to on jest unikalnym identyfikatorem każdego "zrzutu" twojego kodu.![]()
- Możesz filtrować historię według gałęzi, autora, daty lub nawet według słowa w wiadomości commita. To pomaga szybko znaleźć, kto i kiedy pracował nad konkretną częścią funkcjonalności.
- Chcesz znaleźć commit, w którym dodano lub usunięto konkretną linię kodu? W oknie
Logjest pole do wyszukiwania, które szuka nie tylko w wiadomościach, ale też w zawartości samych zmian. - Kliknij prawym przyciskiem myszy na polach edytora kodu i wybierz
Annotate with Git Blame. IDE pokaże obok każdej linii, kto i w którym commicie ostatnio ją zmieniał. To niesamowicie przydatne do zrozumienia, dlaczego kod jest napisany w taki, a nie inny sposób.
5. Niebezpieczna strefa: Force Push
Ustaliliśmy więc, że zmienianie wysłanych commitów to zły pomysł. Ale co jeśli mimo to zmieniłeś swoją lokalną historię (na przykład za pomocą Reset) i teraz różni się ona z historią na serwerze? Przy próbie zwykłego push Git zwróci błąd, chroniąc wspólną historię przed nadpisaniem.
Na takie przypadki istnieje opcja — force push (wymuszona wysyłka). Ta komenda mówi serwerowi: "Zapomnij wszystko, co miałeś. Moja lokalna wersja historii jest jedyną prawdziwą. Zastąp swoją historię moją".
UWAGA! W 99% przypadków użycie force push w projektach zespołowych to katastrofa. Może to bezpowrotnie usunąć commity, które twoi koledzy już pobrali i na których pracują. To równoznaczne z wyrwaniem kartek z bibliotecznej książki i wklejeniem swoich.
Kiedy kategorycznie NIE używać force push:
- Na jakiekolwiek wspólne gałęzie:
main,develop,master. Nigdy. - Na jakąkolwiek gałąź, nad którą pracuje ktoś inny poza tobą.
Jedyny dopuszczalny scenariusz:
Pracujesz w swojej prywatnej feature-branch, której nikt jeszcze nie widział ani nie używał. Zrobiłeś kilka "brudnych" commitów, wysłałeś je na serwer, a potem postanowiłeś je "uczesać" za pomocą Reset. W takim przypadku możesz zrobić force push, żeby zaktualizować swoją gałąź na serwerze przed utworzeniem Pull Request.
W IDE ta opcja zazwyczaj ukryta jest za przyciskiem Push. Twórcy IDE zrobili to celowo, żebyś nie kliknął jej przypadkowo.
Jeśli nie jesteś pewien na 100%, co robisz — nigdy nie używaj force push. Bezpieczniej jest utworzyć nowy commit z poprawkami.
6. Aktualizacja projektu
Zawsze klikaj Update Project na gałęzi main przed rozpoczęciem pracy nad nowym zadaniem. To uchroni cię przed wieloma przyszłymi konfliktami merge i zagwarantuje, że zaczynasz pracę z najbardziej aktualną wersją kodu.
GO TO FULL VERSION