Porównaj rebase i merge obok siebie na żywym grafie commitów, zaplanuj rebase interaktywny z pick, squash, fixup i drop oraz naucz się przerwać lub cofnąć rebase przez reflog.
git rebase odtwarza commity Twojej gałęzi na wierzchu innego commita, dając prostą historię zamiast commita scalającego. Uruchom git rebase main ze swojej gałęzi funkcji, rozwiąż ewentualne konflikty, a potem wpisz git rebase --continue. Użyj git rebase -i, aby połączyć, przeredagować lub usunąć commity, a git rebase --abort, aby się wycofać.
Komendy rebase, które wpiszesz najczęściej
Rebase to komenda git, której ludzie boją się najbardziej, głównie dlatego, że przepisuje commity. Poniższy graf pokazuje dokładnie, co się zmienia przy merge, a co przy rebase, planer pozwala wypróbować rebase interaktywny na przykładowych commitach, a ostatnie sekcje omawiają konflikty, jedną zasadę, która chroni współpracowników, oraz sposób odzyskania gałęzi po nieudanym rebase.
Merge zachowuje prawdziwą historię i dodaje commit scalający, co jest najbezpieczniejsze dla wspólnych gałęzi. Rebase daje prostą linię, łatwiejszą do czytania i do bisect, co pasuje do Twojej własnej gałęzi funkcji przed review. Wiele zespołów robi rebase prywatnie, a merge publicznie.
Jeśli wciąż trwa, git rebase --abort przywraca wszystko. Jeśli już się zakończył, uruchom git reflog, znajdź wpis tuż przed startem rebase i wykonaj git reset --hard do tego hasha. ORIG_HEAD również wskazuje stary wierzchołek zaraz po rebase, chyba że zmieniła go inna komenda.
Nie rób rebase commitów, na których inni już oparli swoją pracę. Rebase tworzy nowe commity z nowymi hashami, więc każdy, kto ma stare, kończy ze zdublowaną historią i mylącymi konfliktami.
Oba składają commit do commita powyżej. squash otwiera edytor, abyś mógł połączyć obie wiadomości; fixup odrzuca wiadomość składanego commita i zostawia wcześniejszą. fixup -C zamiast tego zachowuje wiadomość składanego commita.
Każdy commit jest ponownie nakładany na nową bazę, a commit, który zmienił te same linie co baza, nie może zostać nałożony automatycznie. Edytuj plik, wykonaj na nim git add i uruchom git rebase --continue. Konflikt może pojawić się raz na każdy odtwarzany commit.
git rebase -i otwiera listę todo z jedną linią na commit, najstarszym na górze. Zmień słowo na początku linii, zapisz i zamknij edytor, a git wykona listę od góry do dołu.
Komendy listy todo w git rebase -i
Najpierw zrób fetch, aby main był aktualny, potem rebase, rozwiąż ewentualny konflikt i bezpiecznie wypchnij przepisaną gałąź.
Znajdź linię tuż przed rozpoczęciem rebase i zresetuj do niej gałąź.
--onto przyjmuje trzy punkty: nową bazę, starą bazę i gałąź. Przenoszone są tylko commity po starej bazie.
feature-b powstała z feature-a. To polecenie kładzie na wierzchu main tylko własne commity feature-b.
Merge czy rebase: co dzieje się z historią
Wybierz sposób połączenia gałęzi
Merge
Rebase
commit scalający
Merge zostawia F1 i F2 nietknięte i dodaje jeden nowy commit z dwoma rodzicami.
Rebase kopiuje F1 i F2 na M3. Kopie (oznaczone ') mają nowe hashe; oryginały zostają w tyle.
Planer rebase interaktywnego
Wybierz akcję dla każdego commita, od najstarszego, i zobacz listę todo oraz wynik.
Akcja dla commita {n}
Lista todo, którą otwiera git
Historia po rebase
Pierwsza linia nie może być squash ani fixup: nie ma nad nią commita, do którego można ją złożyć.
Wszystkie commity zostały usunięte. Gałąź wskazywałaby na swoją bazę.
złożone commity: {n}
wiadomość zmieniona
Zacznij za darmo · Bez karty kredytowej