Wpadłem w konflikt scalania. Jak mogę przerwać scalanie?

Użyłem git pulli miałem konflikt scalania:

unmerged:   _widget.html.erb

You are in the middle of a conflicted merge.

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

Ponieważ twoje pullnie powiodło się, to HEAD(nie HEAD^) jest ostatnim „poprawnym” zatwierdzeniem w twoim oddziale:

git reset --hard HEAD

Innym elementem, który chcesz, jest pozwolić, aby ich zmiany zastąpiły zmiany.

Starsze wersje git pozwoliły na użycie „ich” strategii scalania:

git pull --strategy=theirs remote_branch

Ale od tego czasu zostało to usunięte, jak wyjaśniono w tym komunikacie Junio ​​Hamano (opiekun Git). Jak wspomniano w linku , zamiast tego zrobiłbyś to:

git fetch origin
git reset --hard origin

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

Ponadto, jak wspomina @Michael Johnson, jeśli twoja wersja git to> = 1.7.4, możesz także użyć git merge --abort.

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

Ze strony podręcznika git merge

git merge --abortodpowiada git reset --mergeczasowi MERGE_HEADobecności.

MERGE_HEAD jest obecny, gdy trwa scalanie.

Ponadto w odniesieniu do niezatwierdzonych zmian podczas rozpoczynania scalania:

Jeśli masz zmiany, których nie chcesz zatwierdzać przed rozpoczęciem scalania, tylko git stashje przed scaleniem i git stash poppo zakończeniu scalania lub przerwaniu.

git merge --abort

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

Jeśli w momencie rozpoczęcia scalania wystąpiły nieprzewidziane zmiany w drzewie roboczym, git merge --abortw niektórych przypadkach nie będzie można odtworzyć tych zmian. Dlatego zaleca się, aby zawsze zatwierdzać lub ukrywać zmiany przed uruchomieniem git merge.

git merge --abortodpowiada git reset --mergeczasowi MERGE_HEADobecności.

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

To takie proste.

git merge --abort

Sam Git pokazuje rozwiązanie, gdy masz tego typu problemy i uruchom polecenie git status.

git status

Mam nadzieję, że to pomoże ludziom.

Myślę, git resetże potrzebujesz.

Uważaj, git revertco oznacza coś zupełnie innego niż, powiedzmy, svn revert- w Subversion przywrócenie odrzuci twoje (niezatwierdzone) zmiany, przywracając plik do bieżącej wersji z repozytorium, podczas gdy git revert„cofnie” zatwierdzenie.

git resetpowinien zrobić równowartość svn revert, czyli odrzucić niechciane zmiany.

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

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

W przypadku nie połączonego pliku w konflikcie git udostępnia w indeksie wspólną podstawową, lokalną i zdalną wersję pliku. (To jest miejsce, z którego są odczytywane do użycia w 3-drożnym narzędziu różnicowym git mergetool.) Możesz użyć, git showaby je wyświetlić.

# 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 przy użyciu dosłownie wersji zdalnej 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

Dla scenariusza podobnego zrobiłem git fetchi git pull, wtedy zrozumiałem, że nie było przed gałąź gałąź master, co spowodowało niepożądanych konfliktów.

git reset --merge 

To cofnęło się bez resetowania moich lokalnych zmian.

Komentarze sugerują, że git reset --mergejest to alias dla git merge --abort. Warto zauważyć, że git merge --abortjest to odpowiednik tylko git reset --mergebiorąc pod uwagę, że MERGE_HEADjest obecny. Można to odczytać w pomocy git dla polecenia scalania.

git merge --abort jest równoważny git reset --merge, gdy MERGE_HEAD jest obecny.

Po nieudanym scaleniu, gdy nie ma MERGE_HEAD, nieudanego scalenia można cofnąć git reset --merge, ale niekoniecznie za pomocą git merge --abort. Są nie tylko starą i nową składnią tego samego .

Osobiście uważam, że jest git reset --mergeznacznie bardziej wydajny w przypadku scenariuszy podobnych do opisanego i ogólnie nieudane scalenia.

Jeśli skończysz z konfliktem scalania i nie masz nic do zatwierdzenia, ale nadal wyświetlany jest błąd scalania. Po zastosowaniu wszystkich wymienionych poniżej poleceń,

git reset --hard HEAD
git pull --strategy=theirs remote_branch
git fetch origin
git reset --hard origin

Proszę usuń

.git \ index.lock

Plik [wytnij wklej do innej lokalizacji w przypadku odzyskiwania], a następnie wprowadź dowolne z poniższych poleceń w zależności od wybranej wersji.

git reset --hard HEAD
git reset --hard origin

Mam nadzieję, że to pomaga !!!

Alternatywą, która zachowuje stan kopii roboczej jest:

git stash
git merge --abort
git stash pop

Generalnie odradzam to, ponieważ w rzeczywistości przypomina to scalanie w Subversion, ponieważ odrzuca relacje gałęzi w następnym zatwierdzeniu.

Ponieważ Git 1.6.1.3 git checkoutbył w stanie dokonywać transakcji z dowolnej strony scalania:

git checkout --theirs _widget.html.erb

Stwierdziłem, że dla mnie zadziałało (przywróć pojedynczy plik do stanu sprzed scalenia):

git reset *currentBranchIntoWhichYouMerged* -- *fileToBeReset*

Sourcetree

Ponieważ nie dokonujesz scalenia, po prostu dwukrotnie kliknij inny oddział (co oznacza, że ​​go kasujesz), a kiedy zostaniesz zapytany o odrzucenie wszystkich zmian, zgódź się :)