Dlaczego renowacja git wymaga 3-way merge?

Question

Próbuję ustalić, dlaczego rebase wymaga trójstronnego scalenia. Na przykład, jeśli mamy

A1 - A2 
\ 
    B1 

I już wyrejestrowany B1, i chcę wykonać:

git rebase A2 

dlaczego git scalić A2, B1 i A1? Dlaczego A2 i B1 nie wystarczą? Mam na myśli, czy A2 i B1 jako commit nie zawierają pełnej aktualnej migawki drzewa?

Answer 1

Aby przeprowadzić scalenie, Git musi dowiedzieć się, co dokładnie stało się w dwóch gałęziach od wspólnego przodka (A1). Jak już powiedziałeś poprawnie, Git przechowuje migawki zatwierdzeń/drzew, więc aby uzyskać prawdziwy zestaw zmian, musi porównać A2 z A1 i B1 z A1, a następnie połączyć te indywidualne zestawy zmian.

To samo dzieje się w reorganizacji. Aby zastosować zestaw zmian A2 na B1, najpierw musimy obliczyć ten zestaw zmian z różnic między A1 i A2. A następnie możemy zastosować to do B1. Możesz myśleć o rebase jako coś podobnego do automatycznego generowania plików łatek. Najpierw generuje wszystkie pliki łatek ze starego oddziału i stosuje je do bieżącego HEAD.

Potrzebujemy więc wszystkich tych trzech zobowiązań, aby właściwie obliczyć różnice, ponieważ nie możemy dowiedzieć się, co się stało w zatwierdzeniu, patrząc na to zatwierdzenie.