by Vali Shah

jako programista, wielu z nas musi wybierać pomiędzy Merge i Rebase. Przy wszystkich referencjach, które otrzymujemy z Internetu, wszyscy uważają, że ” nie używaj Rebase, może to spowodować poważne problemy.”Tutaj wyjaśnię, czym są merge i rebase, dlaczego powinieneś (a nie powinieneś) ich używać i jak to zrobić.

Git Merge i Git Rebase służą temu samemu celowi. Są one zaprojektowane tak, aby integrować zmiany z wielu gałęzi w jedną., Chociaż ostateczny cel jest taki sam, te dwie metody osiągają go na różne sposoby, a pomocne jest poznanie różnicy, gdy stajesz się lepszym programistą.

to pytanie podzieliło społeczność Gita. Niektórzy uważają, że zawsze powinieneś rebase, a inni, że zawsze powinieneś scalać. Każda strona ma pewne przekonujące korzyści.

Git Merge

Scalanie jest powszechną praktyką dla programistów korzystających z systemów kontroli wersji. Niezależnie od tego, czy gałęzie są tworzone do celów testowych, poprawek błędów czy z innych powodów, scalanie zatwierdza zmiany w innej lokalizacji., Mówiąc dokładniej, scalanie pobiera zawartość gałęzi źródłowej i integruje ją z gałęzią docelową. W tym procesie zmieniana jest tylko gałąź docelowa. Historia gałęzi źródłowej pozostaje taka sama.,da2a4595a”>

Merge Master -> Feature branch

Pros

  • proste i znane
  • zachowuje pełną historię i porządek chronologiczny
  • zachowuje kontekst gałęzi

wady

  • historia zmian może zostać zanieczyszczona przez wiele zmian scalających
  • debugowanie przy użyciu git bisect może stać się trudniejsze

jak to zrobić

scalanie gałęzi głównej do gałęzi funkcji za pomocą checkout I merge polecenia.,

$ git checkout feature$ git merge master(or)$ git merge master feature

spowoduje to utworzenie nowego „Scal commit” w gałęzi feature, która przechowuje historię obu gałęzi.

Git Rebase

Rebase jest kolejnym sposobem integracji zmian z jednej gałęzi do drugiej. Rebase kompresuje wszystkie zmiany w jeden ” patch.”Następnie integruje łatkę z docelową gałęzią.

W przeciwieństwie do scalania, rebasing spłaszcza historię, ponieważ przenosi ukończoną pracę z jednej gałęzi do drugiej. W procesie eliminuje się niechcianą historię.,

Rebases to sposób, w jaki zmiany powinny przejść od góry hierarchii w dół, a scalenia to sposób, w jaki przepływają w górę

rebase feature oddziałuje na master

plusy

  • usprawnia potencjalnie złożoną historię
  • manipulowanie pojedynczym zatwierdzeniem jest łatwe (np.,
  • unika Scal commit „szum” w zajętych repozytoriach z zajętymi gałęziami
  • czyści pośrednie commity, czyniąc je pojedynczym commitem, co może być pomocne dla zespołów DevOps

Cons

  • zgniatanie funkcji do garstki commitów może ukryć kontekst
  • Rebasowanie publicznych repozytoriów może być niebezpieczne podczas pracy zespołowej
  • to więcej pracy: używanie rebase ' a do przechowywania twoja gałąź funkcji zawsze aktualizowana
  • Rebasing ze zdalnymi gałęziami wymaga wymuszenia push., Największym problemem, z jakim borykają się ludzie, jest to, że wymuszają push, ale nie ustawili domyślnego git push. Skutkuje to aktualizacjami wszystkich oddziałów o tej samej nazwie, zarówno lokalnie, jak i zdalnie, co jest straszne.

jeśli przerobisz historię nieprawidłowo i nieumyślnie, może to prowadzić do poważnych problemów, więc upewnij się, że wiesz, co robisz!

Jak to zrobić

Przełącz gałąź funkcji na gałąź master używając następujących poleceń.,

$ git checkout feature$ git rebase master

przenosi całą gałąź funkcji na górę gałęzi głównej. Robi to przez ponowne zapisanie historii projektu poprzez tworzenie zupełnie nowych commitów dla każdego commita w oryginalnej gałęzi (feature).

interaktywny Rebasing

umożliwia to zmianę commitów podczas ich przenoszenia do nowej gałęzi. Jest to bardziej wydajne niż zautomatyzowana rebase, ponieważ oferuje pełną kontrolę nad historią zmian w gałęzi. Zazwyczaj jest to używane do czyszczenia niechlujnej historii przed scaleniem gałęzi funkcji w master.,

$ git checkout feature$ git rebase -i master

spowoduje to otwarcie edytora poprzez listę wszystkich zmian, które mają zostać przeniesione.

pick 22d6d7c Commit message#1pick 44e8a9b Commit message#2pick 79f1d2h Commit message#3

określa dokładnie, jak będzie wyglądała gałąź po wykonaniu rebase. Zmieniając kolejność Bytów, możesz sprawić, że historia będzie wyglądać jak cokolwiek chcesz. Na przykład, możesz używać poleceń takich jak fixup, squash, edit itd., zamiast pick.

którego użyć

więc co jest najlepsze?, Co polecają eksperci?

trudno uogólnić i zdecydować się na jedną lub drugą, ponieważ każda drużyna jest inna. Ale od czegoś musimy zacząć.

zespoły muszą rozważyć kilka pytań podczas ustawiania zasad Git rebase vs.merge. Ponieważ jak się okazuje, jedna strategia przepływu pracy nie jest lepsza od drugiej. To zależy od Twojego zespołu.

rozważ poziom rebasingu i kompetencji Gita w Twojej organizacji. Określ, w jakim stopniu cenisz prostotę zmiany rozmiaru w porównaniu z identyfikowalnością i historią scalania.,

wreszcie, decyzje dotyczące scalania i rebasingu powinny być rozpatrywane w kontekście jasnej strategii rozgałęziania (zapoznaj się z tym artykułem, aby dowiedzieć się więcej na temat strategii rozgałęziania). Skuteczna strategia rozgałęziania jest zaprojektowana wokół organizacji zespołów.

co polecam?

w miarę rozwoju zespołu trudno będzie zarządzać lub śledzić zmiany rozwojowe za pomocą polityki always merge. Aby mieć czystą i zrozumiałą historię zmian, użycie Rebase jest rozsądne i skuteczne.,

biorąc pod uwagę następujące okoliczności i wytyczne, możesz najlepiej wykorzystać Rebase:

  • rozwijasz się lokalnie: jeśli nie udostępniłeś swojej pracy nikomu innemu. W tym momencie powinieneś preferować rebasowanie zamiast scalania, aby zachować porządek w historii. Jeśli masz swój osobisty fork repozytorium i nie jest on udostępniany innym programistom, możesz bezpiecznie rebase nawet po przejściu do swojej gałęzi.
  • Twój kod jest gotowy do przejrzenia: utworzyłeś pull request. Inni przeglądają Twoją pracę i potencjalnie pobierają ją do swojego widelca do lokalnego przeglądu., W tym momencie nie powinieneś rebaseować swojej pracy. Powinieneś utworzyć commity „przerobienia” i zaktualizować swoją gałąź funkcji. Pomaga to w identyfikowalności żądania ciągnięcia i zapobiega przypadkowemu uszkodzeniu historii.
  • przegląd jest gotowy do integracji z docelową gałęzią. Gratulacje! Masz zamiar usunąć swoją gałąź funkcji. Biorąc pod uwagę, że od tego momentu inni deweloperzy nie będą się fetch-scalać w tych zmianach, to jest Twoja szansa na oczyszczenie swojej historii., W tym momencie możesz przepisać historię i złożyć oryginalne commity oraz te brzydkie „przeróbki pr” i „scalanie” w mały zestaw skupionych commitów. Utworzenie jawnego scalenia dla tych zmian jest opcjonalne, ale ma wartość. Rejestruje, Kiedy funkcja jest ukończona do mistrza.

podsumowanie

mam nadzieję, że to Wyjaśnienie dało kilka spostrzeżeń na temat Git merge i GIT rebase. Strategia Merge vs rebase jest zawsze dyskusyjna. Ale być może ten artykuł pomoże rozwiać twoje wątpliwości i pozwoli Ci przyjąć podejście, które działa na twój zespół.