Twoja gałąź funkcji jest za main, a potrzebujesz nowej pracy. Git merge vs rebase to wybór między dwoma sposobami, by ją zdobyć, i oba są poprawne. Różnią się tym, jak wygląda historia potem.

Zbudowaliśmy malutkie repozytorium, uruchomiliśmy oba polecenia i wkleiliśmy prawdziwy wynik poniżej, żebyś porównał rezultat, zamiast go sobie wyobrażać. Dopiero zaczynasz z Gitem? Zacznij od naszego kursu Gita dla początkujących (po angielsku).

Co robią git merge i git rebase

git merge bierze końcówki dwóch gałęzi i je łączy. Jeśli obie mają nowe commity, Git tworzy commit scalający z dwoma rodzicami. Nic, co już istnieje, nie jest zmieniane.

git rebase bierze commity unikalne dla Twojej gałęzi, odkłada je na bok, przenosi gałąź na koniec drugiej, a potem odtwarza Twoje commity jeden po drugim. Odtworzone commity są nowymi commitami z nowymi hashami, choć ich zmiany są te same.

Git merge w praktyce

Nasz punkt wyjścia: commit A na main, dwa commity (F1, F2) na feature i jeszcze jeden commit (M1) dodany później do main. Teraz robimy merge main do feature.

git switch feature
git merge main
git log --oneline --graph

*   f507aab Merge main into feature
|\
| * 8842fb5 M1
* | 082cc6a F2
* | 5a71e3c F1
|/
* 8766865 A

Wykres pokazuje prawdziwą historię: dwie linie pracy, które się połączyły. Oryginalne commity F1 i F2 zachowują swoje hashe. Ceną jest dodatkowy commit scalający, a w ruchliwym projekcie wykres zamienia się w pajęczynę.

Git rebase w praktyce

Ten sam punkt wyjścia, ale tym razem robimy rebase feature na main.

git switch feature
git rebase main
git log --oneline --graph

* 1ff474b F2
* bf9149e F1
* 8842fb5 M1
* 8766865 A

Historia to jedna prosta linia, jakbyś zaczął pracę po M1. Spójrz na hashe: F1 miał 5a71e3c, a teraz ma bf9149e, F2 zmienił się z 082cc6a na 1ff474b. Git je przepisał i dlatego rebase wymaga ostrożności.

Merge i rebase obok siebie

Złota zasada rebase

Nie rób rebase commitów, które istnieją poza Twoim repozytorium. Po rebase Twoja gałąź nie zgadza się już z kopią na serwerze, więc wypchnięcie wymaga wymuszenia. Jeśli kolega zbudował pracę na starych commitach, jego historia rozjeżdża się teraz z Twoją, a uporządkowanie tego jest bolesne.

Rebase własnej, prywatnej gałęzi funkcji jest w porządku. Rebase main lub dowolnej gałęzi używanej przez innych — nie.

Bezpieczny proces pracy zespołu

Ta rutyna utrzymuje czystą historię i nikogo nie zaskakuje. Większość zespołów stosuje ją przed swoim potokiem CI, takim jak ten z naszego poradnika GitHub Actions CI/CD (po angielsku).

git switch feature
git fetch origin
git rebase origin/main        # or: git pull --rebase
# fix conflicts, then: git add <file> && git rebase --continue
git push --force-with-lease   # only on your own branch

--force-with-lease odmawia nadpisania gałęzi na serwerze, jeśli ktoś wypchnął zmiany od Twojego ostatniego fetch, co zwykłe --force po cichu by zniszczyło. Gdy pull request zostanie zatwierdzony, zrób jego merge do main.

Jak cofnąć nieudany rebase

Rebase wygląda destrukcyjnie, ale stare commity przez jakiś czas zostają w reflog Gita, więc możesz wrócić.

git reflog                    # find the commit before the rebase
git reset --hard HEAD@{5}     # example position, check reflog first

Utwórz gałąź zapasową poleceniem git branch backup przed każdym ryzykownym rebase, a odzyskanie sprowadzi się do jednego polecenia. Uruchamiasz bazę danych lub narzędzia w kontenerach? Zajrzyj do naszego kursu Dockera dla początkujących (po angielsku).

Podsumowanie

Merge zachowuje prawdę, rebase utrzymuje ją w porządku. Używaj rebase, by odświeżyć własną gałąź, merge, by ją dostarczyć, i nigdy nie przepisuj historii, od której zależą inni.

Najczęściej zadawane pytania

Ucz się dalej (artykuły po angielsku)