Różnica między Git Rebase a Merge

Git to rozproszony system kontroli wersji - narzędzie do śledzenia zmian wprowadzonych w zestawie plików lub koordynowania pracy w czasie. Jest to często używane przez programistów do koordynowania zmian w kodzie źródłowym oprogramowania i najlepszej części; może być w ogóle używany do śledzenia wszelkiego rodzaju treści. Został specjalnie zaprojektowany do obsługi wszystkiego, od małych do dużych projektów z najwyższą prędkością i wydajnością. Jest niezwykle elastyczny, co oznacza, że ​​jednostki mogą dzielić pracę bezpośrednio między swoimi osobistymi repozytoriami, a grupy mogą koordynować przepływ pracy za pośrednictwem centralnego repozytorium. Pozwala to po prostu dwóm programistom siedzącym w dwóch różnych lokalizacjach na dokonywanie i rejestrowanie zmian niezależnie, wszystko bez centralnego repozytorium.

Scalanie jest powszechną praktyką w Git stosowaną do integracji zmian z jednej gałęzi do drugiej. Scalanie Git to polecenie, które zatwierdza zmiany w innej lokalizacji. Umożliwia programistom pobranie niezależnych wierszy kodu utworzonych przez gałąź Git i zintegrowanie ich w jedną gałąź. To zmienia tylko gałąź docelową, podczas gdy historia gałęzi źródłowej pozostaje. Git rebase to kolejna komenda używana zasadniczo w tym samym celu, ale robi to zupełnie inaczej. Obaj robią to samo - włączają zatwierdzenia z jednej gałęzi do drugiej - ale różnica polega na tym, jak to robią. Podkreślamy kilka kluczowych punktów odróżniających, porównując oba.

Co to jest Git Merge?

Scalanie Git to polecenie, które łączy dwie lub więcej gałęzi historii zatwierdzeń. Scalanie często łączy tylko dwie gałęzie, chociaż Git obsługuje łączenie trzech, czterech lub więcej gałęzi jednocześnie. Scalanie Git jest używane przez Git pull do włączenia zmian z jednej gałęzi do drugiej lub z innego repozytorium. Scalanie musi nastąpić w jednym repozytorium, co oznacza, że ​​wszystkie gałęzie, które muszą zostać połączone, powinny znajdować się w tym samym repozytorium. Sytuacje scalania zwykle wynikają z dwóch lub więcej użytkowników próbujących zaktualizować wspólny kod. Najczęściej użytkownik łączy gałąź z inną gałęzią w swoim lokalnym repozytorium w środowisku lokalnym. Git merge w szczególności integruje zawartość gałęzi źródłowej z gałęzią docelową. Gałąź docelowa zostaje zmieniona, a gałąź źródłowa pozostaje.

Co to jest Git Rebase?

Git rebase to kolejna alternatywa dla scalania służąca do zintegrowania innej gałęzi z gałęzią, w której aktualnie pracujesz, ale zachowuje liniową historię zatwierdzeń. Celem Git rebase jest przeniesienie gałęzi z jednej lokalizacji do drugiej. Ponieważ zatwierdzenia są niezmienne, nie można ich przenosić, więc pociąga to za sobą dokonywanie nowych zatwierdzeń przy użyciu tych samych zestawów zmian i metadanych. Rebase zasadniczo zmienia pojęcie, kiedy i gdzie opracowano sekwencję zatwierdzeń, co powoduje utratę niektórych aspektów historii rozwoju. Oznacza to, że oryginalne zatwierdzenie, na którym pierwotnie bazował rozwój, zostanie zmienione. Skutecznie włącza wszystkie nowe zmiany w gałęzi master, przepisując historię. W rezultacie tworzy nowe zatwierdzenia dla każdego zatwierdzenia w oryginalnej gałęzi.

Różnica między Git Rebase a Merge

1. Podstawy Git Rebase i Merge

- Chociaż zarówno scalanie, jak i rebase są najczęstszymi sposobami integrowania zmian w Git i służą temu samemu celowi - łączeniu wielu gałęzi w jedną - różnica polega na tym, jak to osiągnąć. Git merge integruje zawartość gałęzi źródłowej z gałęzią docelową, zachowując przy tym przodek każdej historii zatwierdzeń, podczas gdy Git rebase uwzględnia wszystkie nowe zatwierdzenia w gałęzi master, przepisując historię, tworząc nowe zatwierdzenia dla każdego zatwierdzenia w gałęzi źródłowej.

2. Działanie Git Rebase i Merge

 - W przypadku scalania Git najpierw przełączasz się na gałąź do scalenia, a następnie używasz polecenia scalania, aby wybrać gałąź do scalenia. Biorąc pod uwagę, że gałąź wskazuje na zatwierdzenie i że zatwierdzenie jest szczegółowością, z którą kojarzysz zmiany, łączenie polecenie łączy się na poziomie oddziału lub zatwierdzenia. Z drugiej strony Rebase jest nieco inny. Najpierw wybierz gałąź do bazy, a następnie użyj polecenia rebase, aby wybrać, gdzie ją umieścić.

3. Cel Git Rebase and Merge

 - Scalenie tworzy nowe zatwierdzenie, które reprezentuje scalenie dwóch gałęzi. Integruje zmiany z różnych równoległych linii rozwoju (gałęzi), tworząc zatwierdzenie scalania. Celem jest połączenie dwóch lub więcej gałęzi razem, łącznie ze wszystkimi zmianami od momentu rozbieżności do obecnej gałęzi. Przewijanie do przodu to domyślne zachowanie scalania w Git. Z drugiej strony Rebasing zmienia indywidualne zatwierdzenia poprzez przepisywanie historii projektu poprzez tworzenie nowych zatwierdzeń dla każdego zatwierdzenia w oryginalnej gałęzi, co z kolei skutkuje historią liniową bez rozbieżnych gałęzi.

4. Historia Git Rebase i Merge

- Scalanie Git nie zmienia historii, zachowując kontekst gałęzi, co oznacza, że ​​istniejące gałęzie nie są w żaden sposób zmieniane. Tworzy nowe zatwierdzenie (chyba że było to szybkie przewijanie do przodu), ale zatwierdzenia pozostają dostępne z gałęzi. Z drugiej strony Git rebase usprawnia potencjalnie złożoną historię. Zatwierdzenia są przepisywane, stare wersje są zapominane, a DAG zmian jest zmieniany. Zatwierdzenia nie są już osiągalne dzięki rebase, co oznacza, że ​​nie możesz już bazować na opublikowanych gałęziach.

Rebase vs. Merge: Tabela porównawcza

Podsumowanie Git Rebase vs. Łączyć

Krótko mówiąc, zarówno scalanie, jak i rebase to dwa sposoby integracji zmian w Git, ale różnią się sposobem, w jaki to robią. Scalanie to jednoetapowa operacja z jednym miejscem rozwiązywania konfliktów, a zatwierdzenia, które były osiągalne z oddziału, są osiągalne. Z drugiej strony Rebase ponownie stosuje każde zatwierdzenie indywidualnie, przepisując historię, tworząc nowe zatwierdzenia dla każdego zatwierdzenia w gałęzi źródłowej. To, co kiedyś było osiągalne, nie jest już osiągalne. Rebase zasadniczo zmienia pojęcie, kiedy i gdzie opracowano sekwencję zatwierdzeń.