Git Pull nie jest możliwe, pliki nie zostały scalone

Przeczytałem wszystkie podobne pytania na ten temat; wydaje się, że żadne z poniższych nie zadziałało:

Delete offending files
git reset --hard HEAD
git stash
git pull

Prawie każda kombinacja, przechowywanie zmian i pobieranie z repozytorium, skutkuje niemożliwymi do połączenia plikami. Chciałbym odrzucić wszystkie lokalne zmiany i po prostu użyć pilota, ale nie mogę ponownie sklonować (ograniczenia przepustowości i wykorzystania Internetu, gdy programista próbuje to zrobić). Jak mam to zrobic?

Po prostu próbowałem:

git stash
git pull

Również nie działał.

Więcej informacji

Jest jedno zatwierdzenie lokalne, a nadrzędny również ma zatwierdzenie. Próbowałem, git pull --rebaseale nadal nie działa poprawnie ... To daje mi błędy - „zamykanie z powodu nierozwiązanego konfliktu”. Jeśli tak git stash, git reset --hard HEAD, git pull --rebase, pojawia się błąd „wyciąganie nie jest możliwe, nie scalono zmian ...”

Powiedz, że pilot jest, origina gałąź jest master, i powiedz, że już się masterwyewidencjonowałeś, spróbuj wykonać następujące czynności:

git fetch origin
git reset --hard origin/master

To po prostu pobiera bieżącą gałąź i wskazuje ją na HEADgałąź zdalną.

OSTRZEŻENIE : Jak stwierdzono w komentarzach, spowoduje to odrzucenie lokalnych zmian i nadpisanie tym, co znajduje się w źródle .

Lub możesz użyć poleceń hydraulicznych, aby zrobić zasadniczo to samo:

git fetch <remote>
git update-ref refs/heads/<branch> $(git rev-parse <remote>/<branch>)
git reset --hard

EDYCJA: Chciałbym krótko wyjaśnić, dlaczego to działa.

.gitFolder może trzymać zobowiązuje dla dowolnej liczby repozytoriów. Ponieważ skrót zatwierdzenia jest w rzeczywistości metodą weryfikacji zawartości zatwierdzenia, a nie tylko losowo wygenerowaną wartością, jest używany do dopasowywania zestawów zatwierdzeń między repozytoriami.

Gałąź to po prostu nazwany wskaźnik do danego skrótu. Oto przykładowy zestaw:

$ find .git/refs -type f
.git/refs/tags/v3.8
.git/refs/heads/master
.git/refs/remotes/origin/HEAD
.git/refs/remotes/origin/master

Każdy z tych plików zawiera hash wskazujący na zatwierdzenie:

$ cat .git/refs/remotes/origin/master
d895cb1af15c04c522a25c79cc429076987c089b

Wszystkie są przeznaczone dla wewnętrznego mechanizmu magazynowania git i działają niezależnie od katalogu roboczego . Wykonując następujące czynności:

git reset --hard origin/master

git wskaże bieżącą gałąź na tę samą wartość skrótu, na którą wskazuje origin / master. Następnie wymusza zmianę katalogu roboczego, aby dopasować strukturę / zawartość pliku do tego skrótu.

Aby zobaczyć, jak to działa, wypróbuj następujące rozwiązania:

git checkout -b test-branch
# see current commit and diff by the following
git show HEAD
# now point to another location
git reset --hard <remote>/<branch>
# see the changes again
git show HEAD

Miałem szczęście

git checkout -f <branch>

w podobnej sytuacji.

http://www.kernel.org/pub//software/scm/git/docs/git-checkout.html

Cofnij usunięcie w GIT

Rozwiązane, używając następującego zestawu poleceń:

git reset --hard
git pull --rebase
git rebase --skip
git pull

Sztuczka polega na tym, aby zmienić bazę zmian ... Mieliśmy problemy z przebudowaniem jednego trywialnego zatwierdzenia, więc po prostu pominęliśmy go za pomocą git rebase --skip (po skopiowaniu plików).

Jeśli kiedykolwiek napotkasz ten problem po uruchomieniu a, git fetcha następnie git nie pozwoli ci na uruchomienie z git pullpowodu konfliktu scalania ( zarówno zmodyfikowanych / nie scalonych plików , jak i abyś był bardziej sfrustrowany, nie pokaże żadnych znaczników konfliktu w plik, ponieważ nie jest jeszcze scalony). Jeśli nie chcesz stracić swojej pracy, możesz wykonać następujące czynności.

przygotować plik.

$ git add filename

następnie schowaj lokalne zmiany.

$ git stash

ściągnij i zaktualizuj swój katalog roboczy

$ git pull

przywróć lokalny zmodyfikowany plik (git automatycznie połączy się, jeśli to możliwe, w przeciwnym razie go rozwiąże)

$ git stash pop

Mam nadzieję, że to pomoże.

Istnieje rozwiązanie, nawet jeśli nie chcesz usuwać lokalnych zmian. Po prostu napraw niescalone pliki (przez git addlub git remove). Więc zrób git pull.

Zakładając, że chcesz odrzucić wszelkie wprowadzone zmiany, najpierw sprawdź dane wyjściowe git status. W przypadku każdego pliku, który obok niego jest napisany „nie scalony”, uruchom git add <unmerged file>. Następnie przejdź do git reset --hard. Pozwoli to pozbyć się wszelkich lokalnych zmian, z wyjątkiem nieśledzonych plików.

Zostałem rozwiązany za pomocą git, usuń niescalony plik lokalnie.

$ git rm <the unmerged file name>
$ git reset --hard
$ git pull --rebase
$ git rebase --skip
$ git pull
Already up-to-date.

Kiedy później wyślę polecenie git:

$ git commit . -m "my send commit"
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

Odpowiedź Ryana Stewarta była już prawie na miejscu. W przypadku, gdy faktycznie nie chcesz usuwać lokalnych zmian, istnieje przepływ pracy, którego możesz użyć do scalenia:

• Biegnij git status. Wyświetli listę niescalonych plików.
• Połącz je (ręcznie itp.)
• Biegać git commit

Git zatwierdzi tylko scalenia do nowego zatwierdzenia. (W moim przypadku miałem dodatkowe dodane pliki na dysku, które nie zostały wrzucone do tego zatwierdzenia).

Następnie Git uważa scalenie za udane i pozwala na przejście do przodu.