Pytanie Jak mogę się dowiedzieć, który błąd Git powoduje konflikty?


Łączę zmiany w upstream z moim projektem, a ostatnio pojawiło się wiele commitów, które wywołały wiele konfliktów scalających. Nie ma sensu, aby spróbować rozwiązać je wszystkie naraz.

Jak mogę się dowiedzieć, które zatwierdzenia powodują konflikt? Dozwolone są dowolne z poniższych:

  • Sposób, aby Git przestał się łączyć, gdy tylko znajdzie konflikt
  • Sposób uczynienia Git listą wszystkich popełnionych konfliktów, w porządku chronologicznym
  • Wszystko, co pozwala mi rozwiązywać konflikty jeden po drugim, w porządku chronologicznym, które nie wiąże się z łączeniem kilku zobowiązań jednocześnie, w nadziei, że natkną się na konflikty

14
2017-08-10 14:37


pochodzenie


Git nieco różni się od svn. Próbuje połączyć wszystkie zatwierdzenia jednocześnie. Możesz wypróbować interaktywny rebase, który stosuje poprawki jeden po drugim i kończy się niepowodzeniem, gdy tylko zostanie znaleziony konflikt. - madhead


Odpowiedzi:


Możesz dawać git imerge a try: to zastosuje twoje zatwierdzenia jeden po drugim, dając ci szansę zrobienia rebase przyrostowo (co oznacza, że ​​możesz rozpocząć zbieranie, przerwać, wznowić później!).

Możesz zobaczyć tutaj porównanie pomiędzy Przyrostowe scalanie vs. bezpośrednie łączenie kontra rebase.


16
2017-08-10 14:55



git imerge jest zdecydowanie przydatny. - John Szakmeister
Dzięki! Jest to również dobre rozwiązanie, ale git-mergemate robi dokładnie to, o czym myślałem domyślnie. git-imerge jest również dobre, ale trochę przesadzone dla moich potrzeb. - Davis Sorenson
Zamiast używać zewnętrznego narzędzia, takiego jak git imerge, możesz też po prostu spróbować zbieranie wiśni szereg poprawek, aby zobaczyć, co konflikty, po jednym na raz (to w zasadzie jak rebase).


Michael Haggerty ma również narzędzie o nazwie git-mergemate który ma find-conflict dowództwo:

git-mergemate find-conflict BRANCH1..BRANCH2

Użyj bisekcji, aby określić najwcześniejsze zatwierdzenie BRANCH2 że     powoduje konflikt po połączeniu z BRANCH1. W rzeczywistości nie     zachowaj wszelkie połączenia.

git-mergemate find-conflict BRANCH1...BRANCH2

Użyj bisekcji, aby znaleźć parę najwcześniejszych zatwierdzeń (jeden z     każdy oddział), które nie łączą się w sposób czysty. W rzeczywistości nie zatrzymuj     wszelkie połączenia.

git imerge może być używany do tworzenia przyrostowego scalania i rozwiązywania konfliktów po drodze, chociaż nie ma odpowiednika find-conflicts w git-mergemate.


5
2017-08-10 16:11



Podążając za linkiem, wygląda na to, że git-mergemate jest właściwie tylko starą wersją git imerge, sugeruje odpowiedź VonC poniżej. Prawdopodobnie powinieneś edytować tę odpowiedź, by bezpośrednio wskazywać imerge. - Mark Amery


Czy jest jakiś powód, dla którego nie chcesz po prostu użyć? rebase (nieinteraktywnie), aby zsynchronizować się ze zmianami w gałęzi upstream? Zatrzyma się, jeśli wystąpi konflikt przy każdym zatwierdzeniu, a następnie można wznowić bazę danych po jej rozwiązaniu. To jak przyrostowe scalanie i jest wbudowane w Gita, nie ma potrzeby korzystania z zewnętrznej wtyczki / narzędzia:

git fetch <remote>
git rebase <remote>/<upstream-branch>
# Conflict on commit X, resolve conflict, then continue the rebase
git rebase --continue

Ostrzeżenie o ponownym zatwierdzeniu przez force push

Zauważ, oczywiście, że przekierowanie twojego lokalnego oddziału zmieni identyfikatory sha jego zatwierdzeń. Jeśli już wypchnąłeś zatwierdzenia, które chcesz ponownie umieścić na pilocie, musisz wymusić nowe zatwierdzenia, aby zastąpić stare, co może stanowić potencjalny problem, jeśli dzielisz swój oddział z innymi osobami . Więcej informacji na temat tych problemów można znaleźć w:


2
2017-08-10 17:43



Rebase jest w porządku, ale często nie chcesz się odnawiać do gałęzi już wypchniętej w górę (również force-commit może nie być opcją) - ideasman42
@ ideasman42 Nie rozumiem, co masz na myśli przez "force commit". Co to ma być? W Git nie ma takiego polecenia ani opcji. Czy masz na myśli siłę? Pchać?
przepraszam, miałem na myśli force-push - ideasman42
@ ideasman42 również oryginalny plakat próbuje scalić zmiany w swoim lokalnym oddziale. Moja odpowiedź nie zmienia podstawy upstream, to rebase nieuszkodzony oddział lokalny w górnej części. Nie ma potrzeby zmuszania do pchania moją odpowiedzią, ponieważ nie powoduje ona ponownego przesunięcia pchnięć.
@ ideasman42 Czy nie rozumiem twojego pierwszego komentarza? Co to znaczy "odradzać się" w oddziale? W pytaniu nie ma też nic, co sugerowałoby, że oryginalny plakat wypchnął swoje lokalne zmiany do zdalnego repo.