Pytanie Wpadłem na konflikt łączący. Jak mogę przerwać scalanie?


użyłem git pull i miał konflikt scalania:

unmerged:   _widget.html.erb

You are in the middle of a conflicted merge.

Wiem, że druga wersja pliku jest dobra, a moja jest zła, więc wszystkie moje zmiany powinny zostać porzucone. Jak mogę to zrobić?


1913
2017-09-19 13:21


pochodzenie


Zdaję sobie sprawę, że jest to bardzo stare pytanie, ale czy chcesz przerwać to cały scalić i pozostawić rozgałęzioną gałąź bez scalania, lub po prostu zignorować ten jeden plik jako część większego scalenia, pozwalając, aby wszystkie pozostałe pliki zostały scalone w normalny sposób? Według mnie twój tytuł oznacza to, co pierwsze, twoje ciało pytanie chce tego drugiego. Odpowiedzi robią jedno i drugie, nie wyjaśniając. - rjmunro
Miałem podobny przypadek przy zatwierdzaniu, mówiąc, że automatyczne scalanie nie powiodło się; Napraw konflikty, a następnie zatwierdz wyniki: [rejected] gh-pages -> gh-pages (non-fast-forward) - Chetabahana
Gwyn, przydałoby się tutaj wybrać akceptowaną odpowiedź. Najczęściej wybierany jest nieco mniej bezpieczny niż niektóre z bardziej aktualnych rozwiązań, więc myślę, że pomogłoby to w wyróżnieniu innych :) - Amicable


Odpowiedzi:


Od twojego pull nie udało się HEAD (nie HEAD^) jest ostatnim "prawidłowym" zatwierdzeniem w Twoim oddziale:

git reset --hard HEAD

Kolejną rzeczą, której pragniesz, jest pozwolenie, aby ich zmiany przejęły twoje zmiany.

Starsze wersje git pozwoliły ci na użycie strategii scalania "ich":

git pull --strategy=theirs remote_branch

Od tego czasu zostało to usunięte, jak wyjaśniono w ta wiadomość od Junio ​​Hamano (opiekun Gita). Jak wspomniano w połączeniezamiast tego zrobiłbyś to:

git fetch origin
git reset --hard origin

1731
2017-09-19 14:33



Zamiast wykonywać twardy reset, możesz zrobić to na bardziej szczegółowym poziomie, wykonując: git fetch origin  -> git reset origin (soft reset, your changes are still present)  -> git checkout file_to_use_their_version_of another_file (steamroll your own changes back to match the origin)    Nigdy więcej nie używam git pull. Ponieważ w walce pomiędzy moim ostatnim kodem a pochodzeniem, pochodzenie powinno zawsze wygrywać, zawsze git fetch i git rebase origin. To sprawia, że ​​moje scalenia i konflikty są bardzo nieliczne. - Kzqai
Zgadzam się. Lubię też najpierw pobierać, a następnie badać zmiany w górę (git log ..@{upstream} lub git diff ..@{upstream}). Potem, podobnie jak ty, dokonam ponownej oceny mojej pracy. - Pat Notz
Jak wspomniano w nowszej odpowiedzi, od wersji 1.6.1 można używać "git reset --merge" - Matt Ball
użyłem git merge -X theirs remote_branch zamiast git pull --strategy=theirs remote_branch tak jak theirs wygląda jak opcja recursive - mlt
Nie ma strategii theirs. - srcspider


Jeśli twoja wersja git jest> = 1.6.1, możesz użyć git reset --merge.

Ponadto, jak wspomina @ Michael Johnson, jeśli twoja wersja git jest> = 1.7.4, możesz również użyć git merge --abort.

Jak zawsze, upewnij się, że nie masz żadnych niezatwierdzonych zmian przed rozpoczęciem scalania.

Od Strona git merge man

git merge --abort jest równa git reset --merge gdy MERGE_HEAD jest obecny.

MERGE_HEAD jest obecny podczas scalania.

Ponadto w odniesieniu do niezatwierdzonych zmian podczas rozpoczynania scalania:

Jeśli masz zmiany, których nie chcesz zatwierdzić przed rozpoczęciem scalania, po prostu git stash je przed scaleniem i git stash pop po zakończeniu scalania lub przerwaniu go.


1592
2018-03-28 23:16



Interesujące - ale podręcznik mnie przeraża. Kiedy dokładnie jest odpowiedni do użycia? Kiedy musiałbyś podać opcjonalne? <commit>? #GitMoment: -o - conny
Zwykle używasz tego, gdy chcesz przerobić scalenie od początku. Nigdy nie musiałem określać opcjonalnego zatwierdzenia, więc domyślne ustawienie (opcjonalne <commit>) jest w porządku. - Carl
Chciałbym, żeby ta odpowiedź miała więcej głosów! W tym momencie wydaje się najbardziej odpowiednim rozwiązaniem w wielu przypadkach. - Jay Taylor
Ponieważ git v1.7.4 git merge --aband również działa. - Michael Johnson
Nawet przy niezamówionych zmianach git był w stanie przywrócić stan przed scaleniem. Miły! - T3rm1


git merge --abort

Przerwij bieżący proces rozwiązywania konfliktów i spróbuj odtworzyć   stan przed scaleniem.

Jeśli podczas scalania wystąpiły niedopasowane zmiany robocze   Rozpoczęty, git merge --abort w niektórych przypadkach będzie to niemożliwe   zrekonstruuj te zmiany. Dlatego zaleca się zawsze   Zatwierdź lub przechowuj zmiany przed uruchomieniem git merge.

git merge --abort jest równa git reset --merge gdy    MERGE_HEAD jest obecny.

http://www.git-scm.com/docs/git-merge


378
2017-11-12 21:40



Jest to dostępne od wersji git v1.7.4. Jest to alias dla git reset --merge. - Michael Johnson
Nie działa przy konflikcie ośmiornicy. - ks1322


W tym konkretnym przypadku użycia, tak naprawdę nie chcesz przerwać scalania, po prostu rozwiń konflikt w określony sposób.

Nie ma też żadnej szczególnej potrzeby resetowania i przeprowadzania scalania z inną strategią. Konflikty zostały poprawnie wyróżnione przez git, a wymóg akceptacji zmian pozostałych stron dotyczy tylko tego jednego pliku.

Dla niezałożonego pliku w git konfliktu udostępniane są wspólne podstawowe, lokalne i zdalne wersje pliku w indeksie. (Tutaj są odczytywane do użycia w 3-kierunkowym narzędziu do porównywania według git mergetool.) Możesz użyć git show aby je zobaczyć.

# common base:
git show :1:_widget.html.erb

# 'ours'
git show :2:_widget.html.erb

# 'theirs'
git show :3:_widget.html.erb

Najprostszym sposobem rozwiązania konfliktu w celu używania wersji zdalnej dosłownie jest:

git show :3:_widget.html.erb >_widget.html.erb
git add _widget.html.erb

Lub, z git> = 1.6.1:

git checkout --theirs _widget.html.erb

73
2017-09-20 10:41



dzięki za podpowiedź. czy nie jest to jednak kiepski słaby interfejs użytkownika git? - Peter
@Peter: Nie jestem przekonany. Pożądany rezultat można uzyskać za pomocą kilku podstawowych poleceń za pomocą prostych opcji. Jakie ulepszenia zaproponowałbyś? - CB Bailey
Myślę że git 1.6.1 polecenie ma dużo sensu i jest dobre. Dokładnie tego chciałem. Myślę, że rozwiązanie sprzed 1.6.1 jest nieeleganckie i wymaga wiedzy o innych częściach git, które powinny być oddzielone od procesu scalania. Ale nowa wersja jest świetna! - Peter


Myślę, że to jest git reset potrzebujesz.

Strzeż się tego git revert oznacza coś zupełnie innego niż, powiedzmy, svn revert - w Subversion powrót będzie odrzucał twoje (niezatwierdzone) zmiany, zwracając plik do aktualnej wersji z repozytorium, podczas gdy git revert "cofa" zatwierdzenie.

git reset powinien zrobić odpowiednik svn revertto znaczy odrzuć niechciane zmiany.


72
2017-09-19 13:25





Ponieważ komentarze sugerują, że git reset --merge to alias dla git merge --abort, warto to zauważyć git merge --abort jest tylko równoważny git reset --mergebiorąc pod uwagę, że a MERGE_HEAD jest obecny. Można to odczytać w pomocy git dla polecenia scalania.

git merge --abort is equivalent to git reset --merge when MERGE_HEAD is present.

Po nieudanym scaleniu, gdy nie ma MERGE_HEAD, nieudane scalenie może zostać cofnięte git reset --merge ale niekoniecznie z git merge --abort, więc są nie tylko starą i nową składnią tego samego.

Osobiście znajduję git reset --merge o wiele potężniejszy w przypadku scenariuszy podobnych do opisanego i nieudanych fuzji w ogóle.


29
2018-04-02 12:16



co właściwie oznacza "nieudane scalenie"? Łącz się z konfliktami lub czymś innym? Lub w celu ponownego sformułowania: kiedy MERGE_HEAD nie jest obecny? Moje następne pytanie jest po to, aby lepiej zrozumieć "git reset --merge". - Ewoks


Od Git 1.6.1.3 git checkout mógł dokonać płatności po obu stronach scalenia:

git checkout --theirs _widget.html.erb

16
2017-07-17 01:29