git rebase - Learning Zone

git rebase to narzędzie do przepisywania historii Gita: zdejmuje commity twojej gałęzi, przewija ją do nowej bazy i nakłada je z powrotem, commit po commicie. Efekt to płaska, liniowa historia bez commitów scalających, które potrafią zamienić log w plątaninę. Używasz go, gdy chcesz wciągnąć najnowsze zmiany z main pod swoją gałąź albo posprzątać własne commity (połączyć, przenazwać, wyrzucić) przed wysłaniem ich do recenzji.

Składnia i najważniejsze opcje

Podstawowa forma: git rebase [-i] [--onto ]

-i, --interactive — tryb interaktywny: otwiera edytor z listą commitów, gdzie wybierasz pick, squash, reword, drop itd.
--onto — pozwala przeszczepić commity na dowolną bazę, niezależnie od tego, z której gałęzi wyrosły. Przydatne przy wycinaniu fragmentu historii.
--continue — wznawia rebase po tym, jak ręcznie rozwiązałeś konflikt i dodałeś pliki przez git add.
--abort — przerywa operację i przywraca gałąź do stanu sprzed rebase. Twoje koło ratunkowe.
--skip — pomija bieżący commit (np. gdy jego zmiany są już w bazie) i idzie dalej.
--autosquash — automatycznie układa commity oznaczone jako fixup! / squash! pod właściwymi commitami w trybie interaktywnym.
--autostash — chowa niezacommitowane zmiany przed rebase i przywraca je po nim, więc nie musisz robić tego ręcznie.
--exec — uruchamia podane polecenie (np. testy) po każdym nałożonym commicie.

Przykłady użycia

git rebase main — przenosi commity bieżącej gałęzi na czubek main, dając aktualną i liniową historię.
git rebase -i HEAD~3 — otwiera edytor z trzema ostatnimi commitami, żebyś mógł je połączyć, przenazwać lub usunąć.
git rebase --onto main feature-old feature-new — przeszczepia commity z feature-new (liczone od feature-old) prosto na main.
git rebase --continue — kontynuuje po rozwiązaniu konfliktu, gdy poprawione pliki są już w poczekalni.
git rebase --autosquash -i main — porządkuje commity fixup! automatycznie podczas interaktywnego rebase na main.

Częste błędy i pułapki

Najważniejsza zasada: nie rebase’uj gałęzi, którą ktoś inny już pobrał. Rebase tworzy nowe commity z nowymi identyfikatorami, więc po git push --force nadpiszesz historię i rozjedziesz repo współpracownikom. Na wspólnych gałęziach (main, develop) używaj raczej git merge.

Gdy pojawi się konflikt, rebase się zatrzymuje — rozwiąż go, zrób git add i dopiero wtedy git rebase --continue. Nie rób tam git commit ręcznie, bo wprowadzisz zamieszanie. Jeśli się pogubisz, git rebase --abort cofa wszystko bez śladu. A gdy wypchnięcie po rebase jest konieczne, sięgaj po bezpieczniejsze git push --force-with-lease zamiast twardego --force — chroni przed nadpisaniem cudzych zmian, których jeszcze nie widziałeś.

Powiązane komendy: git merge, git cherry-pick, git reset, git reflog, git pull –rebase.