Dlaczego reorganizacja git często powoduje mniej konfliktów scalania niż scalanie?

Question

Często słyszałem, jak mówiono, że używanie git rebase redukuje liczbę konfliktów scalania w przeciwieństwie do git merge, ale nigdy nie znalazłem wyjaśnienia, dlaczego tak się dzieje.

Po prostu powtórzenie jednego zestawu zmian w stosunku do innego zestawu zmian nie odrywa w magiczny sposób nieuniknionego konfliktu, gdy dwie osoby modyfikują ten sam wiersz kodu, więc co sprawia, że ​​rebase jest lepsze?

Czy ktoś może podać prosty przykład, w którym scalenie może powodować konflikty, ale nie można go zmienić?

AKTUALIZACJA: Po 3 dodatkowych latach doświadczenia git, doszedłem do przekonania, że ​​moje pierwotne założenie było fałszywe: konflikty są równie prawdopodobne w rebase vs merge. Rebase ułatwia jednak zrozumienie historii, a jeśli to konieczne, wybiera ją lub przewija do tyłu.

Answer 1

Rozwiązujesz konflikty w commitach, gdzie zostałyby wprowadzone, więc w efekcie nie masz żadnych.

Jeśli edytuję linię w mojej gałęzi funkcji, która od tego czasu zmieniła się w gałęzi głównej, i dokonam prostej fuzji, będzie to powodować konflikt.

Jeśli przebiję, zatrzyma się przy zatwierdzeniu, w którym dokonałem tej zmiany iw tym momencie zajmuję się konfliktem.