Różnica między Git ReBase a Merge
W tym artykule omówimy dwa takie narzędzia Rebase i Scalanie oraz ich różnicę. GIT jest jednym z najczęściej używanych kontrolerów wersji rozproszonych DVCS wśród programistów ze względu na jego dynamiczny charakter i ogromną dostępność narzędzi do obsługi wersji. Istnieją dwa sposoby przesyłania naszych zmian z jednej gałęzi do drugiej. Jednym z nich jest użycie Rebase, a drugim jest Scalenie, które jest dość popularne. Poniżej przedstawiamy najlepsze porównanie między Git ReBase a Merge.
Bezpośrednie porównanie Git ReBase vs Scalanie (infografiki)
Poniżej znajduje się 5 najlepszych porównań między Git ReBase a Merge:
Kluczowe różnice między Git ReBase a Merge
Omówmy kluczową różnicę między Git ReBase a Merge:
1. Git Rebase
Git Rebase rozpoczyna pracę od wspólnego zatwierdzenia między dwoma oddziałami. Opanuj i wyróżnij, stąd porównuje oba te elementy i przechwytuje migawkę różnicy dokonanej w jednej z gałęzi, a następnie dodaje ją do innych. Spójrzmy na to za pomocą poniższych zrzutów ekranu.
Wyobraźmy sobie, że mamy gałąź główną i najnowsze zatwierdzenie do niej m2, jak pokazano na powyższym zrzucie ekranu. Z tego zatwierdzenia tworzymy gałąź funkcji i dokonaliśmy pewnych modyfikacji i zatwierdziliśmy z komunikatem f1. Rozważmy teraz, że ktoś połączył swoją pracę z masterem, a teraz najnowsze zatwierdzenie master to m3, a nie m2, jak pokazano poniżej.
Kontynuujemy także prace nad gałęzią funkcji, aby dodać jej najnowsze zatwierdzenie do wersji f2, jak pokazano poniżej.
Jak widać z powyższego zrzutu ekranu, opanowaliśmy najnowsze zatwierdzenie m3 i mamy funkcję, która nie jest aktualna w master, ponieważ została utworzona z migawki m2 zatwierdzenia, która ma najnowsze zatwierdzenie jako f3. Teraz, aby połączyć te wysiłki z generatorem generującym, pokazano poniżej.
Teraz musimy zintegrować powyższe zmiany, które można wprowadzić na dwa sposoby: jeden za pomocą scalania, a drugi za pomocą rebase. Tutaj przyjrzymy się, jak zintegrować z rebase.
$ git checkout feature
Switched to a new branch 'feature'
$ git rebase master
Z powyższego polecenia rebase postaramy się poszukać wspólnego zatwierdzenia zarówno z poziomu master, jak i funkcji, w tym przypadku jest to m2. A potem, ponieważ musimy zmienić bazę master, będzie szukał dodatków, które zostały wykonane przy pomocy master, i wykona migawkę m3 i funkcję rebase od m2 do m3. Więc teraz mamy funkcję z m3 (zamiast m2), zatwierdza f1, f2. Teraz mogę złożyć wniosek o zmianę bazy na funkcję, aby gałąź główna została zaktualizowana o zmiany funkcji. Należy pamiętać, że każda zmiana w systemie głównym musi zostać poddana audytowi. Tutaj pokazuję tylko przykładowy cel.
$ git checkout master
Switched to a new branch 'master'
$ git rebase feature
Teraz zastosujemy najnowszą gałąź funkcji zatwierdzania, którą jest f2, do master, a ostatnią migawką zatwierdzenia master będzie f2. Możesz wyświetlić listę zatwierdzeń za pomocą polecenia git log, ale najpierw musimy sprawdzić, w której gałęzi musimy zobaczyć dziennik jak poniżej.
$ git checkout feature
Switched to a new branch 'feature'
$ git log
Teraz z rebase zintegrowaliśmy aktualizacje funkcji do opanowania. Spróbujmy to osiągnąć poprzez scalenie.
2. Git Merge
Użyjemy powyższego zrzutu ekranu również w celach referencyjnych i możemy osiągnąć to samo, co osiągnęliśmy również przy użyciu bazy zwrotnej i scalania.
Scalanie Git zatwierdza ostatnie zatwierdzenie, które mieliśmy w gałęzi funkcji, i tutaj jest to z zatwierdzeniem f2, który gromadzi wszystkie zmiany i łączy je z najnowszym zatwierdzeniem, które mamy w gałęzi głównej, tutaj m3. Wygląda to na skomplikowane, ale można je łatwo wykonać za pomocą polecenia scalania. Możemy wykonać scalenie bezpośrednie lub scalenie squash i różnicę w obu.
$ git checkout master
Switched to a new branch 'master'
$ git merge feature
Powyższe polecenie weźmie wszystkie zatwierdzenia funkcji i doda również do loga głównego. Aby tego uniknąć, możemy użyć squasha, aby w logu mastera wykonaliśmy po m3 tylko jedno zatwierdzenie i to jest aktualizacja
$ git checkout master
Switched to a new branch 'master'
$ git merge –squash feature
należy zachować ostrożność podczas korzystania z git rebase i starać się tego unikać. Złotą zasadą jest unikanie go za pomocą publicznych oddziałów.
Spójrz na powyższy scenariusz. Może się to zdarzyć, gdy spróbujesz dokonać zmiany bazy master na gałęzi funkcji, a nasza gałąź master jest publiczna, teraz gałąź master jest aktualizowana, ale wszyscy inni pracują na starszej wersji master. Ponieważ zmiana bazy spowoduje zupełnie nowe zobowiązania, git może myśleć, że historia głównego oddziału różni się od wszystkich innych. Jedynym sposobem na rozwiązanie tego problemu jest zsynchronizowanie obu elementów nadrzędnych poprzez scalenie ich z powrotem i uzyskanie wynikowego zestawu zatwierdzeń, które będą mylące.
Tabela porównawcza Git ReBase vs Scalanie
Poniższa tabela podsumowuje porównania między Git ReBase a Merge:
| Podstawa porównania między Rebase a Merge | Rebase | Łączyć |
| Zobowiązania | Zmienia i przepisuje historię, tworząc nowe zatwierdzenie dla każdego zatwierdzenia w gałęzi źródłowej. | Zawiera wszystkie zmiany w źródle, ale zachowuje pochodzenie każdej historii zatwierdzeń. Zawiera wszystkie zmiany w źródle, ale zachowuje pochodzenie każdej historii zatwierdzeń. |
| Wybór | Tutaj najpierw sprawdzamy gałąź, którą należy zmienić, a następnie wybieramy polecenie rebase aby dodać aktualizacje do innych. | Tutaj najpierw sprawdź gałąź, która musi zostać najpierw scalona. Następnie wykonaj operację scalania i ostatnie zatwierdzenie źródła zostaną połączone z najnowszym zatwierdzeniem master. |
| Rozwiązywanie konfliktów | Ponieważ historia zmian zostanie przepisana, aby zrozumieć, że konflikt będzie trudny niektóre przypadki. | Konflikt scalania można łatwo rozwiązać, rozumiejąc błąd popełniony podczas łączenia. |
| złota zasada | Należy używać w oddziałach publicznych, ponieważ historia zatwierdzania może powodować zamieszanie. | Bez większych szkód podczas wykonywania oddziałów publicznych. |
| Osiągalność | Zatwierdzenia, które były kiedyś osiągalne, nie będą już osiągalne po wprowadzeniu zmiany, ponieważ historia zmian została zmieniona. | Zobowiązania pozostaną osiągalne z gałęzi źródłowych. |
Wniosek
Merge i Rebase to dwa potężne narzędzia Git i oba są używane do wprowadzenia zmian w gałęziach, ale musimy zachować ostrożność przy rebase, ponieważ zmieni on historię zmian i użycie ich w publicznych oddziałach może utrudnić pracę innych powodujących zamieszanie. Podczas gdy możesz użyć opcji scalania, ponieważ jej zatwierdzenia są dostępne z gałęzi źródłowej i możesz łatwo rozwiązać konflikty scalania, jeśli mamy odpowiednie zrozumienie.
Polecane artykuły
Jest to przewodnik po najważniejszej różnicy między Git ReBase a Merge. Tutaj omawiamy także kluczowe różnice Git ReBase vs Scalanie z infografikami i tabelą porównawczą. Możesz także zapoznać się z następującymi artykułami, aby dowiedzieć się więcej -
- Git Fetch vs Git Pull - Najważniejsze różnice
- Abstrakcja kontra enkapsulacja | Porównanie 6 najlepszych
- Architektura HBase z zaletami
- Pytania do wywiadu GIT | Top 11
- System kontroli wersji GIT
- Git Push
- Hermetyzacja w JavaScript
- Kompletny przewodnik po zdalnym poleceniu Git
- Trzy etapy cyklu życia Git z przepływem pracy
- Jak korzystać z GIT Cherry-pick z Przykładem?