0Pricing
DevOps Bootcamp · Lekcja

Rebasing a scalanie

Porównaj rebasing i scalanie oraz dowiedz się, kiedy używać każdej z tych metod, aby zachować czystą, liniową historię.

Rebasing a scalanie to bezpłatna lekcja DevOps Bootcamp na CoddyKit. To lekcja 3 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej DevOps Bootcamp, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs DevOps Bootcamp zawiera 4 lekcji w sumie.

Merge czy rebase? Wybór

Podczas pracy z Gitem często okazuje się, że Pana gałąź rozeszła się z inną gałęzią, na przykład gałąź feature z gałęzią main.

Jak połączyć te zmiany? Git oferuje dwie podstawowe strategie: scalanie i zmianę bazy. Obie prowadzą do integracji, ale robią to w zasadniczo różny sposób, co skutkuje odmienną historią projektu.

Scalanie: łączenie historii

Scalanie to domyślny sposób integrowania zmian w Gicie. Podczas scalania jednej gałęzi z drugą Git pobiera zawartość gałęzi źródłowej i łączy ją z gałęzią docelową.

Najważniejszą cechą scalania jest tworzenie nowego commita scalającego. Ten commit ma dwa commity nadrzędne, wyraźnie pokazując, że połączono dwie rozbieżne historie. Zachowuje dokładną historię obu gałęzi.

Wykonywanie scalania w Git

Przyjrzyjmy się prostemu scalaniu. Utworzymy gałąź feature, dodamy commit, a następnie scalimy ją z powrotem z gałęzią main.

git init my_merge_project
cd my_merge_project
echo "Initial content" > file.txt
git add .
git commit -m "Initial commit"

git branch feature
git checkout feature
echo "Feature A" >> feature.txt
git add .
git commit -m "Add feature A"

git checkout main
echo "Main update" >> main.txt
git add .
git commit -m "Update main"

git merge feature

git log --oneline --graph

Scalanie: zalety i wady

Scalanie jest proste i bezpieczne w przypadku współdzielonych gałęzi, ale może prowadzić do „nieuporządkowanej” historii.

  • Zalety:
  • Zachowuje dokładną historię commitów.
  • Jest nieinwazyjne — nie przepisuje istniejących commitów.
  • Jest proste w użyciu i zrozumieniu.
  • Wady:
  • Może tworzyć „zaszumioną” historię z wieloma commitami scalającymi.
  • Graf może wyglądać na złożony, gdy scala się wiele gałęzi.

Rebase: przepisywanie historii

Zmiana bazy to alternatywa dla scalania, która integruje zmiany przez przeniesienie lub połączenie sekwencji commitów z nowym bazowym commitem. Zamiast tworzyć commit scalający, przepisuje historię projektu.

W praktyce commity z gałęzi funkcji są „odtwarzane” na najnowszym commicie gałęzi docelowej, dzięki czemu wygląda to tak, jakby praca od początku była prowadzona na tej gałęzi. Powstaje w ten sposób liniowa historia bez dodatkowych commitów scalających.

Wykonywanie rebase w Git

Spróbujmy teraz tego samego scenariusza z użyciem rebase. Zmienimy bazę gałęzi feature na gałąź main.

Proszę zauważyć, że commit gałęzi feature zostaje ponownie zastosowany na najnowszym commicie gałęzi main, a następnie scalanie typu fast-forward sprawia, że main wskazuje na ten commit.

git init my_rebase_project
cd my_rebase_project
echo "Initial content" > file.txt
git add .
git commit -m "Initial commit"

git branch feature
git checkout feature
echo "Feature B" >> feature.txt
git add .
git commit -m "Add feature B"

git checkout main
echo "Main update 2" >> main.txt
git add .
git commit -m "Update main 2"

git checkout feature
git rebase main

git checkout main
git merge feature

git log --oneline --graph

Rebase: zalety i wady

Zmiana bazy tworzy uporządkowaną historię, ale wiąże się z istotnym ostrzeżeniem dotyczącym współdzielonych gałęzi.

  • Zalety:
  • Tworzy uporządkowaną, liniową historię projektu.
  • Ułatwia przeglądanie i zrozumienie historii commitów.
  • Pozwala uporządkować (połączyć lub zmienić kolejność) commity przed integracją.
  • Wady:
  • Przepisuje historię commitów.
  • Może być niebezpieczna w przypadku commitów, które zostały już wypchnięte do współdzielonego (publicznego) zdalnego repozytorium.

Merge a rebase: porównanie

Oto krótkie podsumowanie najważniejszych różnic:

  • Merge:
  • Tworzy nowy commit scalający.
  • Zachowuje pełną, dokładną historię.
  • Nie modyfikuje istniejącej historii.
  • Graf może być złożony.
  • Rebase:
  • Przepisuje historię i nie tworzy commita scalającego.
  • Skutkuje liniową historią.
  • Jest inwazyjny (zmienia identyfikatory commitów).
  • Graf jest bardzo uporządkowany.

Wybór strategii

Kiedy należy używać poszczególnych strategii?

  • Merge należy stosować, gdy:
  • Pracuje Pan na publicznych lub współdzielonych gałęziach, na przykład main i develop.
  • Potrzebne jest zachowanie dokładnej historii projektu.
  • Chce Pan wyraźnie pokazać moment połączenia rozbieżnych historii.
  • Rebase należy stosować, gdy:
  • Pracuje Pan na prywatnej gałęzi funkcji przed jej wypchnięciem.
  • Chce Pan uzyskać czystą, liniową historię.
  • Chce Pan uporządkować commity gałęzi funkcji (na przykład połączyć je lub zmienić ich kolejność) przed integracją.

Złota zasada: nigdy nie zmieniaj bazy commitów, które zostały już wypchnięte do współdzielonego zdalnego repozytorium! Przepisywanie współdzielonej historii może przysporzyć współpracownikom poważnych problemów.

Szybkie sprawdzenie: merge czy rebase?

Proszę rozważyć właściwości dwóch głównych strategii integracji w Gicie.

Podsumowanie: merge a rebase

W tej lekcji omówiliśmy dwa podstawowe sposoby integrowania zmian w Gicie: scalanie i zmianę bazy.

  • Scalanie łączy historie za pomocą nowego commita scalającego, zachowując wszystkie oryginalne commity.
  • Zmiana bazy przepisuje historię, tworząc liniowy przebieg przez przeniesienie commitów.

Wybór należy dostosować do sposobu pracy zespołu i pamiętać o złotej zasadzie: nigdy nie zmieniać bazy publicznej historii! Zrozumienie tej zasady ma kluczowe znaczenie dla utrzymania uporządkowanego i opartego na współpracy procesu pracy z Gitem.

Często zadawane pytania

Czy lekcja „Rebasing a scalanie” jest bezpłatna?

Tak — pełny tekst „Rebasing a scalanie” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu DevOps Bootcamp, przejdź na CoddyKit PRO. Kurs DevOps Bootcamp zawiera 4 lekcji w sumie.

Co nauczysz się w „Rebasing a scalanie”?

Porównaj rebasing i scalanie oraz dowiedz się, kiedy używać każdej z tych metod, aby zachować czystą, liniową historię. Ćwiczysz DevOps Bootcamp z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć DevOps Bootcamp?

Nie wymagamy żadnego doświadczenia. DevOps Bootcamp w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 3 z 4.

Ile czasu zajmuje lekcja „Rebasing a scalanie”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji DevOps Bootcamp?

Tak. Każda lekcja DevOps Bootcamp zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Przepływ pracy z gałęziami funkcjonalności
  2. Wprowadzenie do przepływu Gitflow
  3. Rebasing a scalanie
  4. Tworzenie oparte na gałęzi głównej
← Powrót do DevOps Bootcamp