Nie jestem pewien, czy jest to „błogosławiony” sposób, aby to zrobić, ale oto, co zrobiłem, aby rozwiązać ten sam problem bez konieczności „forsowania” lub czegoś w tym rodzaju rażącego.
Załóżmy, że twoja historia wygląda mniej więcej tak (a M to flubbed merge):
-A--B--C--M (master points here)
\ /
D----E
Uruchomienie git checkout -b merge_fix <commit ID E>tworzy gałąź, zanim popełnimy jakiekolwiek błędy:
-A--B--C--M (master points here)
\ /
D----E (HEAD and merge_fix point here)
Teraz zróbmy ponownie scalenie w naszym nowym oddziale. Nie możemy się po prostu scalić master, więc musimy ręcznie wybrać zatwierdzenie przed naszym złym scaleniem: git merge <commit ID C>Nie popełniaj tych samych błędów, które popełniłeś ostatnim razem!
-A--B--C--M (master points here)
\ X
D----E-G (HEAD and merge_fix point here)
Zakładając, że zatwierdzenie Gwygląda dobrze, teraz chcemy zsynchronizować się z wierzchołkiem mastergałęzi. To polecenie mówi gitowi, aby zignorował zmiany wprowadzone w celu opanowania i zmusił nasze zmiany, aby stały się wynikiem scalenia:git merge -s ours master
-A--B--C--M (master points here)
\ X \
D----E-G--H (HEAD and merge_fix point here)
Wreszcie (ponownie zakładając, że zatwierdzanie Hwygląda dobrze, chcemy przewinąć do przodu, masteraby uwzględnić nasze stałe scalanie:
git checkout master
git merge merge_fix
To tak naprawdę przesuwa masterwskaźnik gałęzi H, ale skorzystam z okazji, aby trochę wyczyścić moją grafikę ASCII:
-A--B--C--M--H (HEAD, master, and merge_fix all point here)
\ X /
D----E--G
I masz to! pomyślnie wykonałeś scalenie bez unieważniania historii!