Rebasing jest procesem przenoszenia lub łączenia sekwencji commitów do nowego commita bazowego. Rebasing jest najbardziej użyteczny i łatwy do wizualizacji w kontekście przepływu pracy rozgałęzienia funkcji. Ogólny proces może być wizualizowany w następujący sposób:

z punktu widzenia zawartości, rebasing zmienia bazę gałęzi z jednego commita na drugi, co sprawia, że wygląda tak, jakbyś utworzył swoją gałąź z innego commita., Wewnętrznie, Git osiąga to poprzez tworzenie nowych commitów i stosowanie ich do określonej bazy. Bardzo ważne jest, aby zrozumieć, że nawet jeśli gałąź wygląda tak samo, składa się ona z całkowicie nowych commitów.

użycie

głównym powodem rebasingu jest zachowanie liniowej historii projektu. Na przykład rozważ sytuację, w której gałąź główna postępowała od czasu rozpoczęcia pracy nad gałęzią funkcji., Chcesz otrzymywać najnowsze aktualizacje gałęzi master w swojej gałęzi funkcji, ale chcesz zachować czystą historię swojej gałęzi, aby wyglądała tak, jakbyś pracował nad najnowszą gałęzią master. Daje to późniejszą korzyść z czystego scalenia gałęzi funkcji z powrotem do gałęzi głównej. Dlaczego chcemy zachować „czystą historię”? Korzyści płynące z posiadania czystej historii stają się namacalne podczas wykonywania operacji Git w celu zbadania wprowadzenia regresji. Bardziej realny scenariusz to:

1. błąd jest identyfikowany w gałęzi master., Funkcja, która działała pomyślnie, jest teraz zepsuta.
2. programista bada historię gałęzi master używając git log ze względu na „czystą historię” programista jest w stanie szybko wyjaśnić historię projektu.
3. programista nie może określić, kiedy błąd został wprowadzony za pomocą git log, więc programista wykonujegit bisect.
4. ponieważ historia Gita jest czysta, git bisect ma wyrafinowany zestaw commitów do porównania podczas szukania regresji., Programista szybko znajduje commit, który wprowadził błąd i jest w stanie odpowiednio zareagować.

Dowiedz się więcej o git log i GIT bisect na ich indywidualnych stronach użycia.

masz dwie opcje integracji funkcji w gałęzi master: scalanie bezpośrednio lub rebasing, a następnie scalanie. Pierwsza opcja powoduje 3-way merge i merge commit, podczas gdy druga powoduje fast-forward merge i doskonale liniową historię. Poniższy diagram pokazuje, w jaki sposób rebasing na gałęzi master ułatwia szybkie scalanie.,

Rebasing jest powszechnym sposobem integrowania zmian w źródle do lokalnego repozytorium. Ściąganie zmian z git merge skutkuje zbędnym zatwierdzeniem merge za każdym razem, gdy chcesz zobaczyć, jak postępuje projekt. Z drugiej strony, rebasing jest jak powiedzenie: „chcę oprzeć moje zmiany na tym, co wszyscy już zrobili.”

nie rebaseuj publicznej historii

jak już wcześniej omawialiśmy w przepisywaniu historii, nigdy nie powinieneś rebaseować commitów po ich wypchnięciu do publicznego repozytorium., Rebase zastąpi stare commity nowymi i będzie wyglądało na to, że ta część historii Twojego projektu nagle zniknęła.

Git Rebase Standard vs Git Rebase Interactive

Git rebase interactive jest wtedy, gdy Git rebase akceptuje argument-- i. Oznacza to ” Interactive.”Bez żadnych argumentów polecenie działa w trybie standardowym. W obu przypadkach Załóżmy, że stworzyliśmy oddzielną gałąź funkcji.,

 # Create a feature branch based off of master git checkout -b feature_branch master # Edit files git commit -a -m "Adds new feature" 

Git rebase w trybie standardowym automatycznie pobierze commity w bieżącej działającej gałęzi i zastosuje je do nagłówka przekazanej gałęzi.

 git rebase 

to automatycznie zmienia aktualną gałąź na, która może być dowolnym odniesieniem do zatwierdzania (na przykład ID, Nazwa gałęzi, znacznik lub względne odniesienie doHEAD).

uruchomieniegit rebase przy użyciu flagi-i rozpoczyna interaktywną sesję rebasingu., Zamiast ślepo przenosić wszystkie zmiany do nowej bazy, interaktywny rebasing daje możliwość zmiany poszczególnych zmian w procesie. Pozwala to na czyszczenie historii poprzez usuwanie, dzielenie i modyfikowanie istniejącej serii zatwierdzeń. To jest jak Git commit --amend na sterydach.

 git rebase --interactive 

zmienia bieżącą gałąź na ale używa interaktywnej sesji rebasingu. Otworzy się edytor, w którym można wprowadzić polecenia (opisane poniżej) dla każdego commitu, który ma zostać zmieniony., Polecenia te określają, w jaki sposób poszczególne commity zostaną przeniesione do nowej bazy. Możesz również zmienić kolejność listy zatwierdzeń, aby zmienić kolejność samych zatwierdzeń. Po określeniu komend dla każdego commita w rebase, Git rozpocznie odtwarzanie commitów przy użyciu komend rebase. Polecenia edycji rebasingu są następujące:

dodatkowe polecenia rebase

jak opisano na stronie Historia przepisywania, rebasing może być używany do zmiany starszych i wielu zatwierdzeń, zatwierdzonych plików i wielu wiadomości., Chociaż są to najczęstsze aplikacje, git rebase ma również dodatkowe opcje poleceń, które mogą być przydatne w bardziej złożonych aplikacjach.

• git rebase -- d oznacza, że podczas odtwarzania commit zostanie odrzucony z ostatniego połączonego bloku commit.
• git rebase -- p pozostawia commit tak, jak jest. Nie zmodyfikuje on wiadomości ani zawartości zatwierdzenia i nadal będzie pojedynczym zatwierdzeniem w historii gałęzi.
• git rebase -- x podczas odtwarzania wykonuje skrypt powłoki wiersza poleceń na każdym zaznaczonym zatwierdzeniu., Przydatnym przykładem może być uruchomienie pakietu testowego bazy kodowej na określonych commitach, co może pomóc w identyfikacji regresji podczas rebase.

podsumowanie

interaktywny rebasing daje pełną kontrolę nad tym, jak wygląda historia twojego projektu. Daje to programistom dużą swobodę, ponieważ pozwala im tworzyć „brudną” historię, skupiając się na pisaniu kodu, a następnie wrócić i posprzątać po fakcie.

większość programistów lubi używać interaktywnej rebase do polerowania gałęzi funkcji przed połączeniem jej z główną bazą kodu., Daje to im możliwość zgniecenia nieistotnych commitów, usunięcia przestarzałych i upewnienia się, że wszystko inne jest w porządku przed przejściem do „oficjalnej” historii projektu. Dla wszystkich innych będzie to wyglądało tak, jakby cała funkcja została opracowana w jednej serii dobrze zaplanowanych commitów.

prawdziwą moc interaktywnego rebasingu można zobaczyć w historii powstałej gałęzi master. Dla innych wygląda na to, że jesteś genialnym programistą, który zaimplementował nową funkcję z idealną ilością commitów za pierwszym razem., W ten sposób interaktywny rebasing może utrzymać czystą i sensowną historię projektu.

opcje konfiguracyjne

istnieje kilka właściwości rebase, które można ustawić za pomocągit config. Te opcje zmienią wygląd wyjścia git rebase.

• rebase.stat: wartość logiczna domyślnie ustawiona na false. Opcja włącza wyświetlanie wizualnej zawartości diffstat, która pokazuje, co zmieniło się od ostatniej degradacji.

• rebase.autoSquash: wartość logiczna, która włącza zachowanie--autosquash.,

• rebase.missingCommitsCheck: można ustawić na wiele wartości, które zmieniają zachowanie rebase wokół brakujących zatwierdzeń.,/tr>

  error

  Stops the rebase and prints removed commit warning messages

  ignore

  Set by default this ignores any missing commit warnings
  • rebase.instructionFormat: A git log format string that will be used for formatting interactive rebase display

  Advanced rebase application

  The command line argument --onto can be passed to git rebase., Gdy w trybie Git rebase --onto polecenie rozszerza się do:

    git rebase --onto 

  --onto polecenie umożliwia bardziej rozbudowaną formę lub rebase, która pozwala przekazać konkretne refy jako końcówki rebase.
  Załóżmy, że mamy przykład repo z gałęziami takimi jak:

    o---o---o---o---o master \ o---o---o---o---o featureA \ o---o---o featureB 

  featureB jest oparty na featureA, jednak zdajemy sobie sprawę, że featureB nie jest zależny od żadnej ze zmian w featureA i może być po prostu rozgałęziony poza master.

    git rebase --onto master featureA featureB 

  featureA to., master staje się I featureB jest referencją do tego, coHEAD z wskaże. Wyniki są następujące:

    o---o---o featureB / o---o---o---o---o master \ o---o---o---o---o featureA 

  zrozumienie zagrożeń związanych z rebase

  jedno zastrzeżenie, które należy wziąć pod uwagę podczas pracy z Git Rebase, to konflikty scalające, które mogą być częstsze podczas pracy z rebase. Dzieje się tak, jeśli masz długowieczną gałąź, która zbłądziła od mistrza., W końcu będziesz chciał zmienić baze na master i w tym czasie może ona zawierać wiele nowych commitów, z którymi zmiany Twojej gałęzi mogą być w konflikcie. Można temu łatwo zaradzić, zmieniając często Twoją gałąź na master i dokonując częstszych commitów. Argumenty linii poleceń--continue I--abort mogą być przekazywane dogit rebase aby przyspieszyć lub zresetować rebase podczas rozwiązywania konfliktów.

  poważniejszym zastrzeżeniem rebase jest utrata commitów z interaktywnego przepisywania historii., Uruchamianie rebase w trybie interaktywnym i wykonywanie poleceń podrzędnych, takich jak squash lub drop, usunie commity z natychmiastowego dziennika Twojej gałęzi. Na pierwszy rzut oka może to wyglądać tak, jakby commity na stałe zniknęły. Używającgit reflog te zmiany mogą zostać przywrócone i cały rebase może zostać cofnięty. Aby uzyskać więcej informacji na temat używania git reflog aby znaleźć utracone commity, odwiedź naszą stronę dokumentacji Git reflog.

  Sam Git Rebase nie jest poważnie niebezpieczny., Realne przypadki zagrożenia pojawiają się podczas przepisywania historii interaktywnych rebas i wymuszania przesyłania wyników do zdalnej gałęzi współdzielonej przez innych użytkowników. Jest to wzorzec, którego należy unikać, ponieważ ma on możliwość nadpisania pracy innych zdalnych użytkowników podczas ich ciągnięcia.

  odzyskiwanie z rebase

  Jeśli inny użytkownik dokonał rebase i wymusił przesunięcie do gałęzi, do której się zobowiązujesz,git pull nadpisze wszelkie commity, które masz w oparciu o poprzednią gałąź z końcówką, która została wymuszona., Na szczęście, używając git reflog możesz uzyskać reflog zdalnej gałęzi. Na blogu reflogu zdalnej gałęzi możesz znaleźć ref zanim został on ponownie opublikowany. Następnie możesz zmienić swoją gałąź na zdalny ref używając opcji --onto, jak omówiono powyżej w sekcji Advanced Rebase Application.

  podsumowanie

  w tym artykule omówiliśmy użyciegit rebase. Omówiliśmy podstawowe i zaawansowane przypadki użycia oraz bardziej zaawansowane przykłady., Niektóre kluczowe punkty dyskusji to:

  • Git rebase standard vs tryby interaktywne
  • opcje konfiguracji Git rebase
  • Git rebase –on
  • Git rebase stracił commity