Do tej pory rozważaliśmy idealny scenariusz: piszesz kod, robisz commity, tworzysz Pull Request. Ale w prawdziwym życiu często coś idzie nie tak: możesz popełnić błąd w kodzie, zrobić commit z niewłaściwą wiadomością albo po prostu zrozumieć, że poszedłeś w złym kierunku. W tej lekcji omówimy, jak rozwiązywać najczęstsze problemy.
1. Rollback – cofanie zmian przed commitem
Scenariusz: zmieniłeś plik, ale okazało się, że wszystkie twoje poprawki są błędne i chcesz szybko przywrócić plik do stanu, w jakim był po ostatnim commicie.
Użyj funkcji Rollback:
- Otwórz kartę
Commit. - Znajdź na liście zmieniony plik, który chcesz „cofnąć”.
- Kliknij go prawym przyciskiem myszy i wybierz
Rollback.
IDE ostrzeże cię, że zmiany zostaną utracone. Zgódź się, a plik natychmiast wróci do swojej ostatniej wersji zapisanej w Git. To najprostszy i najbezpieczniejszy sposób cofnięcia lokalnych zmian.
2. Reset – usuwanie lokalnych commitów
Scenariusz: zrobiłeś jeden lub kilka commitów, ale jeszcze nie wykonałeś push. Zorientowałeś się, że te commity są błędne i chcesz je całkowicie usunąć, jakby nigdy ich nie było.
Użyj funkcji Reset:
- Otwórz kartę
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 go prawym przyciskiem myszy i wybierz
Reset Current Branch to Here....
W otwartym oknie zostaniesz poproszony o wybór trybu resetu. Najbardziej radykalny – Hard.
Uwaga! Tryb Hard bezpowrotnie usuwa wszystkie commity po wybranym, a także 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órych nikt jeszcze nie widział (tych, które nie zostały wysłane na GitHub).
3. Co zrobić po pushu?
Scenariusz: wykonałeś push i dopiero potem zauważyłeś w nim błąd.
Gdy tylko commit trafi na zdalny serwer, staje się częścią wspólnej historii projektu. Próba przepisania tej historii może stworzyć ogromne problemy dla twoich kolegów. Wyobraź sobie, że już pobrali twoje zmiany i zaczęli na ich podstawie swoją pracę.
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. Dzięki temu historia pozostaje uczciwa i zrozumiała dla wszystkich.
4. Spojrzenie w przeszłość: zaawansowana praca z logiem
Znamy już kartę Git -> Log, ale to nie tylko lista commitów, lecz potężne narzędzie do dochodzeń.
- Hash commita (Commit Hash): zapewne zauważyłeś w logu ciąg liter i cyfr, na przykład
a1b2c3d. Ten hash jest unikalny, pozwala dokładnie odwoływać się do dowolnego punktu w historii projektu. Rzadko będziesz musiał używać go ręcznie, ale warto wiedzieć, że to unikalny identyfikator każdej „migawki” twojego kodu.![]()
- Możesz filtrować historię po gałęzi, autorze, dacie, a nawet po słowach w komunikacie commita. To pomaga szybko znaleźć, kto i kiedy pracował nad określoną częścią funkcjonalności.
- Chcesz znaleźć commit, w którym dodano lub usunięto konkretną linię kodu? W oknie
Logjest pole wyszukiwania, które przeszukuje nie tylko komunikaty, ale także treść samych zmian. - Kliknij prawym przyciskiem myszy w obszarze edytora kodu i wybierz
Annotate with Git Blame. IDE pokaże przy każdej linii, kto i w jakim commicie zmieniał ją po raz ostatni. To niezwykle przydatne do zrozumienia, dlaczego kod jest napisany właśnie tak.
5. Strefa zagrożenia: Force Push
Ustaliliśmy zatem, że modyfikowanie wysłanych commitów to zły pomysł. Ale co, jeśli jednak zmieniłeś swoją lokalną historię (na przykład za pomocą Reset) i teraz różni się ona od historii na serwerze? Przy próbie wykonania zwykłego push Git zwróci błąd, chroniąc wspólną historię przed nadpisaniem.
Na takie przypadki istnieje opcja – force push (wymuszone wysyłanie). Ta komenda mówi serwerowi: „Zapomnij wszystko, co miałeś. Moja lokalna wersja historii jest jedyną słuszną. Zamień swoją historię na 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 podstawie pracują. To tak, jakby wyrwać strony ze wspólnej bibliotecznej książki i wkleić własne.
Kiedy kategorycznie NIE WOLNO używać force push:
- Na jakiekolwiek współdzielone 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 gałęzi feature, której nikt jeszcze nie widział i 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 wykonać force push, aby zaktualizować swoją gałąź na serwerze przed utworzeniem Pull Request.
W IDE ta opcja jest zwykle ukryta pod przyciskiem Push. Twórcy IDE zrobili to celowo, aby nie kliknąć jej przypadkowo.
Jeśli nie jesteś w 100 % pewien, co robisz, – nigdy nie używaj force push. Bezpieczniej jest utworzyć nowy commit z poprawkami.
6. Aktualizowanie projektu
Zawsze klikaj Update Project na gałęzi main przed rozpoczęciem pracy nad nowym zadaniem. To uchroni cię przed wieloma przyszłymi konfliktami scalania i zapewni, że zaczynasz pracę z najbardziej aktualną wersją kodu.
GO TO FULL VERSION