gitMergeVsRebase

Git – merge vs rebase różnice

Niniejszy post pokaże różnice merge vs rebase poparte praktycznymi przykładami. Zademonstruje łączenia gałęzi za pomocą tych dwóch poleceń. W poprzednim wpisie tej serii opisuje działanie merge i rebase zapraszam 🙂

Przykladowe Repo

Repozytorium dla tego wpisu, na nim będziemy bazować każdy przykład:
ExampleRepo
A tutaj kod tworzący powyższy obraz repozytorium

No fast forward

Słowo wstępu, przy każdym poleceniu merge dodaję przełącznik no-ff ‚no fast forward’. Jest to merge, który dodaje nowy komit z informacją ‚Merge branch feature into master’. W historii zobaczymy ‚wybrzuszenie’ tak jak na rys.1. Bez przełącznika uzyskamy historię liniową.

NoFastForward

Merge branchB into master

Pracując na naszym repo, wykonamy łączenie gałęzi master z branchB. Zawartość gałęzi branchB zostanie ustawiona (dołączona) na samym szczycie gałęzi master w postaci jednego komita, sclającego rozwidlenie.

Obraz z poziomu gitk all
GitMergeBranchB

Rebase branchB

Jeżeli wklejasz komendy, aby zobaczyć w praktyce działanie, to za każdym poleceniem rebase lub merge przywracaj repo do stanu z Przykładowe repo.
Wykonamy polecenie rebase na gałęzi branchB, przejdziemy na gałąź master i spróbujemy z mergować branchB do master

gitRebaseBranchB2

Wykonanie opcji merge dla powższego przykładu nie jest potrzebne, ponieważ wykonując operację rebase na gałęzi branchB w tym konkretnym przypadku, gałąź ta zostanie ‚wpasowana’ w historie komitów gałęzi master.

Rebase master & merge branchB

rebaseMaster
Wykonując rebase na gałęzi master, git uporządkowuje naszą historię w taki sposób, że komity z master są jeden po drugim, a komity z branchB są na szczycie gałęzi master.

Wrócimy na gałąź master i z mergujemy gałąź branchB do master

gitRebaseMasterGitMergeMaster

Wykonując operację git merge branch no-ff dodajemy na szczcie naszej historii komit z informacją, że w tym konkretnym komicie jest merge innej gałęzi. Przez dodanie opcji no-ff nasza historia nie jest w 100% liniowa, tylko zawiera ‚wybrzuszenie’ dla komitów zawierających się w branchB. Ten zabieg widać bardzo dobrze na obrazku. Takie postępowania pozwala nam zachować czytelną historię, dzięki której widzimy, na jakim etapie były dodawane nowe elementy.

Merge vs rebase

Pierwszą rzeczą, jaką należy sobie uświadomić to, że git rebase i git merge, rozwiązują ten sam problem. Oba polecenia służą do łączenie gałęzi.

Przy używaniu polecenie rebase, należy wykonywać tę komendę zawsze na ‚branchach’ niewypchniętych do repozytorium. Rebase powinien być wykonywany na naszych prywatnych gałęziach (czyli takich, których, żaden z członków nie widzi).

Komenda git rebase ‚przepisuje’ historię projektu poprzez utworzenie nowych SHA-1 dla każdego komita w oryginalnej gałęzi. Przykład rozjaśni, o co mi chodzi, cały czas korzystamy z przykładowego repo:

Przed rebase  Po rebase
* e5a6a64 (branchB) b5.txt * 002ac7f (HEAD -> branchB) b5.txt
* 459d356 b4.txt * 2436d4c b4.txt

Zwróć uwagę na SHA-1 komitów z komentarzem od ‚b1.txt’ do ‚b5.txt.’ przed rebasem i po rebase, są różne 🙂

 

Podsumowanie

Tym krótkim w treść, ale obszernym w kod i obrazy, przedstawiłem działanie merge i rebase. Sam jestem zwolennikiem merge, ponieważ lubię widzieć w historii jeden komit informujący, że w tym miejscu został wykonany merge</span>.

Jak wygląda u was praktyka stosowania łączenia gałęzi? 🙂

 

 

Pozdro 🙂

Dodaj komentarz

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

*