Rebase czy merge? Krótka instrukcja bez religijnych wojen

W każdym zespole prędzej czy później pada pytanie: „robimy rebase czy merge?”. Odpowiedź brzmi: jedno i drugie, tylko w innych miejscach. Obie komendy łączą zmiany z dwóch gałęzi, ale zostawiają po sobie inną historię.

Merge: historia taka, jaka była

git merge tworzy nowy commit z dwoma rodzicami. Nic nie jest przepisywane, więc to bezpieczne nawet na gałęziach, z których korzystają inni. Ceną jest historia z rozgałęzieniami, która przy dużym ruchu wygląda jak plan metra.

git switch main
git merge feature/login

Rebase: historia taka, jaką chcesz pokazać

git rebase bierze Twoje commity i odtwarza je na nowej bazie. Historia jest liniowa i czyta się ją jak opowieść. Ale commity dostają nowe hashe — to nowe obiekty, nawet jeśli zmiany są te same.

git switch feature/login
git rebase main
# po rozwiązaniu konfliktu:
git add . && git rebase --continue

Złota zasada: nie rób rebase gałęzi, na której pracuje ktoś poza Tobą.

Jak to połączyć w praktyce

Sytuacja	Wybór
Aktualizacja własnej gałęzi o zmiany z main	rebase
Porządki przed pull requestem	rebase -i
Wlanie gotowej funkcji do main	merge (lub squash)
Gałąź współdzielona przez kilka osób	merge

Dwie linijki konfiguracji, które polecam każdemu: git pull zamiast zbędnych commitów scalających będzie robił rebase, a lokalne niezapisane zmiany zostaną automatycznie odłożone na bok.

git config --global pull.rebase true
git config --global rebase.autoStash true

Push po rebase

Po rebase zwykły git push zostanie odrzucony, bo historia się różni. Zamiast --force używaj --force-with-lease: nadpisze gałąź tylko wtedy, gdy nikt w międzyczasie nic do niej nie dorzucił.

Coś poszło nie tak? Reflog

Git prawie nic nie gubi. git reflog pokazuje, gdzie był HEAD przed każdą operacją, więc nieudany rebase cofa się jedną komendą.

git reflog
# a1b2c3d HEAD@{4}: rebase (start): checkout main
git reset --hard HEAD@{5}