Jaka jest różnica między poleceniami merge i rebase w systemie kontroli wersji Git?

merge łączy gałęzie, tworząc nowy commit z dwoma rodzicami, zachowując historię zmian. rebase przenosi commity jednej gałęzi na inną, liniowo porządkując historię, ale zmieniając hasze commitów.

• Przy merge:

  • Tworzony jest nowy commit scalający.
  • Historia gałęzi pozostaje jawna.
  • Mogą wystąpić konflikty, które rozwiązuje się w nowym commicie.

  # Przykład użycia merge
  git checkout gałąź-funkcjonalność
  git merge main
  # Rozwiązywanie konfliktów, jeśli są
  git commit -m "Scal główną gałąź z gałęzią-funkcjonalność"
  

• Przy rebase:

  • Commity "są przenoszone" i nakładane na docelową gałąź.
  • Historia staje się liniowa, może wyglądać "czyściej".
  • Hasze przeniesionych commitów się zmieniają.
  • Konflikty mogą wystąpić dla każdego przenoszonego commitu.
  • Nie zaleca się dla gałęzi, które już zostały opublikowane i używane przez innych programistów, ponieważ zmienia to historię.

  # Przykład użycia rebase
  git checkout gałąź-funkcjonalność
  git rebase main
  # Rozwiązywanie konfliktów, jeśli są (powtarzać dla każdego konfliktowego commitu)
  git add .
  git rebase --continue
  # lub git rebase --skip, aby pominąć commit
  # lub git rebase --abort, aby anulować
  

Cecha	merge	rebase
Zmiana historii	Zachowuje historię	Nadpisuje historię (przepisuje)
Commity	Tworzy commit scalający	Przenosi istniejące commity
Linia historii	Nie (gałęzie rozchodzą się)	Tak (upraszcza historię)
Podejście	Niekonfliktowe	Potencjalnie destrukcyjne
Zastosowanie	Publiczne, wspólne gałęzie	Lokalnie, prywatne gałęzie