Czym różni się Rebase i Merge

Czym różni się Rebase i Merge

Podczas pewnej rozmowy padło pytanie: „Czym różni się rebase od merge?”. Odpowiedzią było: „Przecież jedno i drugie robi dokładnie to samo”. Cała rzecz w tym, że o ile na końcu obu operacji możemy spodziewać się tego samego wyniku tak same operacje i przebiegają całkiem inaczej.

Feature branch

Kto miał styczność z systemem kontroli wersji zna schemat dodawania funkcjonalność do tworzonego projektu. Tworzymy nowy branch, robimy swoje, a kiedy uważamy, że warto dodać gotowy kawałek do głównej gałęzi (master) robimy merge… albo rebase… no właśnie – co robimy? Załóżmy, że dwie różne części projektu reprezentują dwa kwadraty – obecnie mające kolor szary. W pewnym momencie decydujemy się rozwijać pewną część projektu na osobnej gałęzi nazwanej niepozornie myAwesomeFeature. Podczas tworzenia niebieskiego kwadratu na gałęzi myAwesomeFeature na masterze dokonaliśmy zmian, zmieniając lewy kwadrat na żółty. W tym momencie flow wyglądało by następująco:
merge vs rebase

Merge

Zacznijmy od merge – jako bardziej rozpoznawanego i popularnego rozwiązania. Merge myAwesomeFeature do gałęzi master wykonalibyśmy w następujący sposób:
git checkout master
git merge myAwesomeFeature

Pierwsza różnica pomiędzy merge i rebase polega na tym, że wykonując merge, tworzymy nowy commit, który reprezentuje każdą zmianę jaka miała miejsce na połączonej gałęzi od momentu oderwania się od mastera.

 

Pracując w małych projektach jest to w zupełności wystarczające i pewnie nie odczujemy różnicy używania rebase względem merge. Jednak gdy projekt jest większy to mergowanie wszystkiego zostawia trudne do odczytania logi a co za tym idzie – znacznie utrudnia to śledzenie flow tworzonych zmian.

operacja merge
merge hell by hackernoon
Dobrze zilustrowany przykład przez hackernoon.com

Przykład po lewej stronie to merge-mania, która objawia się prezentowanymi logami. Pracując w gronie kilku developerów może nie osiągniemy tak spektakularnych tworów, jednak w projekcie, w którym nierzadko pracuje 20-30 programistów, moglibyśmy osiągnąć znacznie ciekawsze pofałdowania logów.

Dla jasności sprawy – merge nie jest zły, merge jest fajny i bardzo przydatny ale nie powinien być nadużywany. Rada od developerów brzmi następująco: Niech merge zarezerwowany będzie dla commitów dużych, ważnych i stanowiących ważny krok w tworzonym projekcie.

Rebase

Wyjaśniając rebase można polegać na jego nazwie – zamienia bazę gałęzi na inną pozycję.

Załóżmy, że tym razem nie chcemy dodatkowego merge-commita a raczej podpiąć nasze zmiany pod mastera. W takim przypadku możemy odpalić:

git checkout myAwesomeFeature
git rebase master

To co się dzieje to przeniesienie całej gałęzi myAwesomeFeature na koniec gałęzi master – bez zbędnych – dodatkowych commitów. 

Dodatkowo zyskujemy całkowicie liniową historię zmian – bez widocznych powyżej autostrad mergów. 

Minusem takiego rozwiązania jest strata informacji np. w którym miejscu wyszliśmy z mastera.

Powyższe przykłady to podstawowe różnice pomiędzy merge i rebase. Jeśli chcesz zostać „a git guru” warto odwiedzić Atlassian tutorials, gdzie dowiedzieć się można znacznie więcej o merge, rebase i więcej o samym „gicie”.  

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Na górę