W ostatnim wpisie opisywałam, jak używać komendy merge do łączenia zmian. Dzisiaj czas na kolejną komendę – rebase.

Początek historii będzie taki sam, jak poprzednio. Dwóch autorów (autor1, autor2) pracuje na dwóch osobnych branchach (branch1, branch2). Każdy z nich wprowadza zmiany w tym samym pliku UserController.

Autor1: zmiany na branch1

Zmiany na tym branchu polegały na zmianie nazwy parametru metody w UserController.

Autor2: zmiany na branch2

Zmiany na tym branchu polegały na dodaniu sprawdzenia, czy obiekt nie jest nullem.

Po zakończeniu wprowadzania zmian czas na rebase. Jak to wygląda?

Będąc na swoim branchu branch1, musi wpisać komendę:

Dzięki niej zaktualizuje się historia pochodząca z głównego brancha. Należy jednak pamietać, żeby ten branch był zgodny z aktualną wersją, która jest na serwerze!

Wynikiem takiej komendy dla autor1 jest następujący komunikat:

Jak widać, wersja brancha master_xmpl zawarta na branchu branch1 jest aktualna. Rebase nie jest potrzebny, można zrobić merge bez problemów.

Żeby sprawdzić, czy należy robić rebase, wystarczy (będąc na głównym branchu) wywołać komendę

Parametr –ff-only gwarantuje, że merge nie powiedzie się, jeśli historia głównego brancha jest różna między branchami i podczas próby merge występują jakieś konflikty. Konflikty mogą być rozwiązane automatycznie (tzw. fast-forward) – wtedy nie tworzy się dodatkowy commit (przy ustawieniach domyślnych, które oczywiście mogą zostać zmienione). Ale mogą być również konflikty takie, które nie mogą one być automatycznie rozwiązane, musimy sami ingerować w kod. Po nich powstaje dodatkowy commit.

W tym przypadku nie jest potrzebny rebase, ponieważ merge przeszedł bez żadnych konfliktów.

Po rozwiązaniu konfliktów z danego etapu rebase, należy użyć komendy

w celu kontynuowania rebase i przejścia do kolejnego etapu.

W naszym przypadku po ręcznym rozwiązaniu konfliktu i wpisaniu powyższej komendy zostaną wprowadzone zmiany i otrzymamy wynik:

Jeśli nie chcemy z jakiegoś powodu wprowadzić zmian z danego commita, należy użyć komendy:

Jeśli zorientujemy się, że np. coś poszło nie tak i chcemy przerwać rebase, wystarczy komenda:

Wszystkie zmiany zostają cofnięte i możemy np. zacząć rebase od nowa.

Gdy autor2 skończy rebase, czy wystarczy, że wrzuci zmiany serwer i już może oddać kod do review? Niekoniecznie. Etap rozwiązywania konfliktów jest bardzo podatny na błędy. Osoba robiąca rebase (w tym przypadku autor2) powinien sprawdzić, czy kod się kompiluje, czy wszystkie testy przechodzą i ewentualnie sprawdzić, czy działają zmieniane ostatnio funkcjonalności. Dopiero po tym etapie można wysłać kod do review.

Oczywiście należy pamiętać o tym, że komenda rebase nie jest lekiem na całe zło. Sprawdza się bardzo dobrze w sytuacji, którą przedstawiłam – gdy mamy PRYWATNY branch, z którego nie korzysta nikt inny i który chcemy zaktualizować do najnowszej wersji np. głównego brancha. W momencie, gdyby nasz branch byłby publiczny i współdzielony z inną osobą – jeśli zrobilibyśmy rebase, powstałby bałagan w historii i zsynchronizowanie wersji obydwu osób mogłoby zająć trochę czasu.

Należy pamiętać o tym, że rebase zmienia historię. To znaczy, że nasze commity, które zmieniły swojego parenta, zostają skopiowane jako nowe commity, z nowymi id:

Wcześniej commit „renamed parameter” miał id c87da2 – rebase w tym przypadku nie był potrzebny, więc id commita zostało takie samo. W przypadku drugiego commita „added check if user is null”, który miał id 7adb71 stało się inaczej. Zrobiliśmy rebase, więc został mu przyznany nowy id 72cfae.