Rebase podczas synchronizacji repozytorium – polecenie git pull –rebase

Opublikowane przez Tomasz Prasołek w dniu 4 października 20184 października 2018

Wszystkie zmiany w kodzie, które robimy lokalnie w jakimś momencie musimy wrzucić do zdalnego repozytorium. Git nie pozwoli Nam wrzucić swoich zmian, jeśli nie mamy zsynchronizowanego repozytorium. Przed wrzuceniem naszej pracy musimy ściągnąć ostatnie commity wrzucone przez innych. Do ściągnięcia najnowszej wersji repozytorium służy polecenie git pull – o tym na pewno wszyscy wiedzą.

Jednak jak ono naprawdę działa?

git pull

Na początku swojej nauki gita dowiedziałem się, że najnowsze zmiany w repozytorium ściąga się poleceniem git pull. Nie wiedziałem dokładnie jak to działa. Ściąga, wrzuca lokalnie, jak jest konflikt to trzeba rozwiązać i już. Dopiero po pewnym czasie dowiedziałem się, że to polecenie jest równoważne wykonaniu dwóch innych poleceń:

git fetch
git merge origin/master

Obraz jest wart więcej niż tysiąc słów 🙂 , więc zobaczmy jak to wygląda. Zakładamy, że pracujemy na branchu master. Sytuacja wyjściowa:

git fetch – ściąga ostatnie zmiany z brancha origin/master i zapisuje je u nas na dysku. Robi tylko to.

git merge origin/master – robi merge brancha origin/master do naszego lokalnego brancha master. W wyniku tej operacji powstaje nowy commit tzw. merge commit.

git pull –rebase

Jednak możemy zmienić to zachowanie. Zamiast merge zrobić rebase. Wystarczy dodać opcję na końcu:

git pull --rebase

Wtedy to zadziała tak:

git fetch
git rebase origin/master

A czemu tak robić? W czym to jest lepsze?

Kilka powodów:

• Historia repozytorium będzie prosta.
• Nasze commity nie wypchnięte na serwer zostaną przesunięte na samą górę, a te właśnie ściągnięte wejdą przed nie. Przed zrobieniem pusha, nasze commity zawsze będą na samej górze, nie będą pomieszanie z tymi już ściągniętymi.
• Łatwiej będzie wykonać polecenie git bisect, ale o tym napiszę w innym wpisie.

Kiedy nie używać git pull –rebase

Ogólnie trzeba uważać na polecenie rebase. Jednak podczas używania opcji rebase wraz z poleceniem git pull zawsze mamy do czynienia z tymi samymi branchami: origin/master i master. Nie widzę żadnego przypadku, aby używanie git pull --rebase mogło spowodować jakieś szkody.

Julius Musseau na blogu we wpisie  Too much fun with “git pull –rebase” sprawdza polecenie git pull --rebase w sytuacji gdzie 2 osoby pracują na feature branchu, robią git push --force i stosują git pull --rebase. Zawsze rebase się udaje.

Decyzja czy używać czy nie powinna zależeć od własnych preferencji lub ustaleń w zespole.

Rebase jako ustawienie domyślne

Może powiedzieć teraz: “Ok, ta opcja jest bardzo fajna. Ale czy za każdym razem muszę wpisywać całe polecenie git pull --rebase? Nie musisz 🙂 Wystarczy dodać wpis do ustawień globalnych git i od teraz zawsze polecenie git pull będzie robiło rebase:

git config --global pull.rebase true

Jeśli jednak z jakichś powodów chcemy zrobić merge, to można wykorzystać opcję –no-rebase:

git pull --no-rebase

Również można tę opcję ustawić bezpośrednio w Visual Studio, ale dopiero od wersji 15.5. Tę opcję można włączyć w zakładce Team Explorer, w panelu Settings:

Wszystkie zrzuty ekranu pokazujące repozytorium git są zrobione w narzędziu Visualize Git: https://github.com/git-school/visualizing-git

Źródło: https://www.git-scm.com/docs/git-pull