git pull nie powiedzie się „nie można rozwiązać problemu” „nie można zaktualizować lokalnego odwołania”


606

Używając git 1.6.4.2, kiedy próbowałem git pull , otrzymuję ten błąd:

error: unable to resolve reference refs/remotes/origin/LT558-optimize-sql: No such file or directory
From git+ssh://remoteserver/~/misk5
 ! [new branch]      LT558-optimize-sql -> origin/LT558-optimize-sql  (unable to update local ref)
error: unable to resolve reference refs/remotes/origin/split-css: No such file or directory
 ! [new branch]      split-css  -> origin/split-css  (unable to update local ref)

Próbowałem git remote prune origin, ale to nie pomogło.


Odpowiedzi:


929

Spróbuj wyczyścić lokalne repozytorium za pomocą:

$ git gc --prune=now
$ git remote prune origin

man git-gc (1):

git-gc - Cleanup unnecessary files and optimize the local repository

git gc [--aggressive] [--auto] [--quiet] [--prune=<date> | --no-prune]

       Runs a number of housekeeping tasks within the current repository, such as compressing file revisions
       (to reduce disk space and increase performance) and removing unreachable objects which may have been
       created from prior invocations of git add.

       Users are encouraged to run this task on a regular basis within each repository to maintain good disk
       space utilization and good operating performance.

man git-remote (1):

git-remote - manage set of tracked repositories

git remote prune [-n | --dry-run] <name>

           Deletes all stale remote-tracking branches under <name>. These stale branches have already been
           removed from the remote repository referenced by <name>, but are still locally available in
           "remotes/<name>".            

96
Dlaczego to działa? Jaki problem rozwiązuje?
Ikke

5
Drugie polecenie działało dla mnie. Najwyraźniej miałem zepsute odniesienie do właśnie utworzonej zdalnej gałęzi. Nie jestem pewien, jak to się stało, ale cieszę się, że było to proste rozwiązanie. Dzięki Vitek!
JGTaylor

1
To działało idealnie! Chciałbym też wyjaśnić, co to robi i dlaczego to działa. Dzięki!
ArielSD

4
Czy git remote prune originpolecenie będzie działać na mojej lokalnej kopii roboczej lub na zdalnym repozytorium?
user1438038,

3
@ user1438038 Nie powinno to usuwać żadnych oddziałów i aktualizować tylko zdalne referencje w lokalnej kopii roboczej. Więcej informacji tutaj: stackoverflow.com/questions/20106712/…
Zengineer

606

Zdarzyło mi się również. W moim przypadku złym referencją był master, a ja wykonałem następujące czynności:

rm .git/refs/remotes/origin/master
git fetch

To spowodowało, że git przywrócił plik ref. Potem wszystko znów działało zgodnie z oczekiwaniami.


1
Zrobiłem to samo i to rozwiązało mój problem. Kiedy otworzyłem plik w Notepad ++, był on wyraźnie uszkodzony.
maj

83
upewnij się, że wybierasz plik, który sprawia problemy, zamiast master
bia.migueis,

6
@ bia.migueis: nie zaszkodzi nic, jeśli przypadkowo usuniesz także master - zostanie również zaktualizowany przy następnym pobieraniu.
naught101

2
Jeśli jest to podmoduł, znalezienie ref może być nieco trudne. Najpierw sprawdź, czy .gitjest to folder, wykonując go, ls -lajeśli nie, sprawdź zawartość pliku .git, aby znaleźć rzeczywisty folder .git, w którym znajdują się odnośniki. .gitzawartość pliku w moim przypadku: gitdir: ../.git/modules/my-submodule-name
CCoder

1
Dwa razy w ciągu ostatniego roku wróciłem, aby to naprawić i ponownie, to jedyna poprawka, która faktycznie działa.
Ted

131

To zrobiło dla mnie zadanie:

git gc --prune=now

5
To zadziałało. Dzięki za uratowanie mi dnia! @Bernd Jakieś możliwe wyjaśnienie polecenia?
nashcheez


1
Pracowałem też dla mnie. Nie git remote prune origin
musiałem

87

Dla mnie zadziałało usunięcie plików, które zgłaszają błędy z folderu .git/refs/remotes/origin/.


to zrobiło! Ale z ciekawości wiesz, dlaczego ten błąd przyszedł? (wszystko działało dobrze i nagle pewnego dnia pojawił się ten błąd). A także wiesz, jak usunięcie pliku rozwiązało go?
Shreyans

Miło to słyszeć, również to naprawiło. Szczerze mówiąc, nie mam pojęcia, co spowodowało pojawienie się błędu. Myślałem, że jeden z plików w folderze nie jest zsynchronizowany. Ponieważ żadna z innych poprawek, które znalazłem, nie działała dla mnie, użyłem tego w ostateczności.
Brian van Rooijen

Działa świetnie! Zauważ, że musisz usunąć wszystkie pliki, które powodują problem (na podstawie otrzymywanego raportu o błędach), tak jakbyś tylko usunął jeden i spróbował go wyciągnąć.
Rayee Roded

1
Jedną z możliwych przyczyn może być awaria systemu, jak opisałem w mojej odpowiedzi . Wiele aplikacji GUI Git okresowo uruchamia Git na twoim repozytorium (aby odświeżyć status), a jeśli twój system ulegnie awarii podczas Git manipuluje referencjami, mogą one zostać przepisane z NULLs.
David Ferenczy Rogožan

53

Spróbuj:

git gc --prune=now

git remote prune origin

git pull

26
Chociaż może to odpowiedzieć na pytanie autorów, brakuje w nim niektórych wyjaśnień i / lub linków do dokumentacji. Fragmenty surowego kodu nie są bardzo pomocne bez niektórych fraz wokół nich. Bardzo pomocne może się okazać, jak napisać dobrą odpowiedź . Edytuj swoją odpowiedź.
Roy Scheffers

Dokładnie o to chodzi. Nie wystarczy poprawić kod i to wszystko. Mam nadzieję, że jest wyjaśnienie
Musikero31,

1
git gc --prune = teraz aktualizuje lokalne repozytorium podczas usuwania niepotrzebnych plików. Działa mi dobrze.
Vasyl Gutnyk

44

Wykonaj następujące polecenia:

rm .git/refs/remotes/origin/master

git fetch

git branch --set-upstream-to=origin/master

Na wszelki wypadek, jeśli chcesz wiedzieć, co to jest .git/refs/remotes/origin/master, przeczytaj sekcję Piloty w Git References .


1
Czy możesz wyjaśnić, co to jest .git / refs / remotes / origin / branchName? To rozwiązanie działało dla mnie
caitcoo0odes,

44

Chciałbym tylko dodać, jak to się dzieje, że referencja się psuje.

Możliwa przyczyna pierwotna

W moim systemie (Windows 7 64-bit), gdy zdarza się BSOD , niektóre z zapisanych plików referencyjnych (najprawdopodobniej obecnie otwierane / zapisywane w momencie BSOD) są zastępowane NULLznakami (ASCII 0).

Jak wspomnieli inni, aby to naprawić, wystarczy usunąć niepoprawne pliki referencyjne i ponownie pobrać lub ponownie pobrać repozytorium.

Przykład

Błąd: cannot lock ref 'refs/remotes/origin/some/branch': unable to resolve reference 'refs/remotes/origin/some/branch': reference broken

Rozwiązanie: usuń plik%repo_root%/.git/refs/remotes/origin/some/branch


1
Ten sam scenariusz na Windows 10 64bit - praca w repozytorium git, gdy zdarza się BSOD. error: cannot lock ref 'refs/remotes/origin/master': unable to resolve reference 'refs/remotes/origin/master': reference broken. Próbowano wykonać git pullpo usunięciu pierwszego pliku fatal: update_ref failed for ref 'HEAD': cannot lock ref 'HEAD': unable to resolve reference 'refs/heads/master': reference broken. Po usunięciu drugiego pliku git pull origin masterpowiodło się.
cjmcdonn,

39

Miałem ten sam problem i rozwiązałem go, przechodząc do pliku, w którym był błąd:

\repo\.git\refs\remotes\origin\master

Ten plik był pełen zer. Zastąpiłem go najnowszym ref z github.


2
Miał ten sam problem, ale plik .git/refs/remotes/origin/masterbył po prostu pusty. Rozwiązano problem, usuwając go.
zinovyev

38

W moim przypadku problem został rozwiązany po usunięciu wszystkich plików odniesienia do usunięcia z katalogu .git.

Jeśli spojrzysz na wiadomość, dowiesz się, które pliki musisz usunąć (konkretnie).

Pliki do usunięcia znajdują się pod .git/refs/remotes.

Właśnie usunąłem wszystkie pliki i uruchomiłem gc prune

git gc --prune=now

Potem wszystko działa dobrze.


W moim przypadku po prostu usuwam .git / refs / piloty, a następnie aktualizuję i przepycham serwer i działało.
Faraz Ahmed

Dzięki Uri. W moim przypadku właśnie usunąłem pliki w obszarze referencji / pilotów / pochodzenia / funkcji i po prostu zrobiłem - git pull
Deepboy

26

Wyjaśnienie : Wygląda na to, że gałęzie zdalnego repozytorium (w Github / bitbucket) zostały usunięte, chociaż lokalne odniesienia nie zostały zaktualizowane i wskazują na nieistniejące odniesienia.

Aby rozwiązać ten problem:

git fetch --prune
git fetch --all
git pull

Do dodatkowej lektury - Odniesienia z dokumentacji Github :

git-fetch - Pobieraj obiekty i referencje z innego repozytorium

--all Pobierz wszystkie piloty.

--prune Po pobraniu usuń wszystkie zdalne gałęzie śledzenia, które już nie istnieją na pilocie.


1
To zadziałało dla mnie
Onengiye Richard,

1
Dzięki, zadziałało dla mnie.
Sam

17

git fetch --prune naprawiłem ten błąd dla mnie:

[marc.zych@marc-desktop] - [~/code/driving] - [Wed May 10, 02:58:25]
[I]> git fetch
error: cannot lock ref 'refs/remotes/origin/user/janek/integration/20170505': 'refs/remotes/origin/user/janek/integration' exists; cannot create 'refs/remotes/origin/user/janek/integration/20170505'
From github.com:zooxco/driving
 ! [new branch]            user/janek/integration/20170505 -> origin/user/janek/integration/20170505  (unable to update local ref)
From github.com:zooxco/driving
[marc.zych@marc-desktop] - [~/code/driving] - [Wed May 10, 02:58:30]
[I]> git fetch --prune
 - [deleted]               (none)     -> origin/user/janek/integration

Zakłada się jednak, że obrażająca gałąź została usunięta na pilocie.


Twój przykład wydaje się niekompletny: nie pokazuje tego --prune, co widzę. Porada: usuń bezużyteczne monity o podanie hasła po wklejeniu przykładów.
MarkHu

Masz absolutną rację - pominąłem wynik polecenia fetch, ale po prostu umieściłem go w przykładzie. Dziękujemy za wskazówkę dotyczącą usuwania hasła hasła!
marczych

11

Jeśli błąd „nie można zaktualizować lokalnego odwołania”, powtarza się, nawet po zastosowaniu odpowiedzi Vojtecha Vitka lub Michela Krämera , możesz mieć złe referencje w lokalnym repozytorium ORAZ.

W takim przypadku należy zastosować obie poprawki bez ciągnięcia lub wciskania między ...

rm .git/refs/remotes/origin/master
git fetch
git gc --prune=now
git remote prune origin

Dla mnie trwałe rozwiązanie zostało osiągnięte dopiero po zastosowaniu obu poprawek przed push / pull.


1
Dzięki za to. zwróć uwagę, że zastąpiłem „master” gałęzią, która zawiodła, np. - rm .git / refs / remote / origin / develop
Damien Sawyer

1
Dziękuję za odpowiedź, naprawdę pomogłem!
naffiq

1
To zadziałało dla mnie
autor: Jeevan

10

Aby odpowiedzieć na to krótko, ten problem pojawia się, gdy lokalny ma jakieś informacje o pilocie i ktoś zmienia coś, co sprawia, że ​​pilot i twoje zmiany nie są synchronizowane.

Otrzymywałem ten problem, ponieważ ktoś usunął zdalną gałąź i ponownie utworzył tę samą nazwę.

Aby poradzić sobie z takimi problemami, pobierz lub pobierz ze zdalnego.

git remote prune origin

lub jeśli używasz dowolnego GUI, wykonaj pobieranie ze zdalnego.

wprowadź opis zdjęcia tutaj



3

Spróbuj tego:

git pull origin Branch_Name

Branch_Name, gałąź, w której aktualnie jesteś.

Jeśli zrobisz tylko git pull , pobiera również wszystkie inne utworzone nazwy gałęzi.

Dlatego otrzymujesz to:

! [new branch]      split-css  -> origin/split-css  (unable to update local ref)

2

Dla mnie miałem lokalny oddział o nazwie feature/phase2i zdalny oddział feature/phase2/data-model. Przyczyną problemu był konflikt nazw, więc usunąłem mój lokalny oddział (możesz zmienić nazwę, jeśli ma coś, co trzeba zachować)


Ten sam problem tutaj - nasz problem dotyczył także nazw komputerów Mac / PC, co utrudniało zauważenie (jedna nazwa była pisana wielkimi literami, druga nie - i działało na PC, ale nie na Macu)
rocksteady

2

Gdyby git gc --prune=now dawka ci nie pomoże. (pech jak ja)

Zrobiłem to, usuwając projekt lokalnie i ponownie klonując cały projekt.


Jest to podejście „Mam komunikat o błędzie, więc kupiłem nowy komputer”, którego nie spodziewałem się, że otrzymam jakieś opinie na tej stronie.
Stephan Vierkant

2

Korzystam z Tower iz jakiegoś powodu moja nazwa folderu to .git/refs/remotes/origin/Github. Zmiana na małe litery .git/refs/remotes/origin/githubrozwiązała problem.


1

Miałem ten sam problem. wykonuję następujące kroki

1) zmień oddział, który ma problem, na inny oddział

2) usuń ten oddział

3) Kasa ponownie.

Uwaga: - Możesz ukryć niezatwierdzone zmiany i odłożyć je z powrotem.



0

Miałem ten sam problem z aktualizacją kompozytora. Ale dla mnie zadziałało to dopiero po wyczyszczeniu pamięci podręcznej kompozytora i usunięciu zawartości folderu dostawcy:

rm -rf vendor/*
git gc --prune=now
git pull
composer clear-cache
composer update my/package

0

Wystąpił ten problem podczas próby sklonowania z git bundleutworzonego pliku, żadna inna odpowiedź nie zadziałała, ponieważ nie mogłem sklonować repozytorium (więc git gcusunięcie i edycja plików nie wchodziła w rachubę).

Był jednak inny sposób, aby to naprawić - plik źródłowy pliku .bundlezaczynał się od:

# v2 git bundle
9a3184e2f983ba13cc7f40a820df8dd8cf20b54d HEAD
9a3184e2f983ba13cc7f40a820df8dd8cf20b54d refs/heads/master
9a3184e2f983ba13cc7f40a820df8dd8cf20b54d refs/heads/master

PACK.......p..x...Kj.0...: (and so on...)

Usunięcie czwartej linii za pomocą vima naprawiło problem.


0

Miałem ten problem podczas korzystania z SourceTree. Spróbowałem ponownie pociągnąć i zadziałało. Myślę, że zbyt szybko wiedźmowałem gałęzie (kasa) :).

Moja sytuacja różni się nieco od plakatu, ponieważ moje repozytorium działa stosunkowo kooperacyjnie, bez widocznego uszkodzenia.


0
 # remove the reference file of the branch "lost"
 rm -fv ./.git/refs/remotes/origin/feature/v1.6.9-api-token-bot-reader

 # get all the branches from the master
 git fetch --all

 # git will "know" how-to handle the issue from now on
 #     From github.com:futurice/senzoit-www-server
 # * [new branch]      feature/v1.6.9-api-token-bot-reader ->
 # origin/feature/v1.6.9-api-token-bot-reader

 # and push your local changes
 git push

0

Napotkano ten sam problem, gdy repozytorium zostało usunięte i utworzone o tej samej nazwie. Działało to tylko wtedy, gdy ponownie ustawiłem zdalny adres URL, jak poniżej;

git zdalny początek adresu URL [GIT_REPO_URL]

Sprawdź zdalny adres URL:

git remote -v

Teraz wszystkie polecenia powinny działać jak zwykle.


0

Właśnie wpadłem na problem dzisiaj.

Metoda rozwiązywania problemów: Z SourceTree na serwerach Windows możesz spróbować uruchomić go jako administrator. To rozwiązuje mój problem „niemożności aktualizacji lokalnego ref” w Atlassian Source Tree 2.1.2.5 w Windows Server 2012 R2 w domenie.

Jeśli możesz za bardzo replikować tę sytuację, oznacza to, że problem jest spowodowany problemem z uprawnieniami. Lepiej przeanalizować i znaleźć główną przyczynę - prawdopodobnie niektóre określone pliki są własnością innych użytkowników i tak dalej - w przeciwnym razie wystąpi niepożądany efekt uboczny: będziesz musiał uruchomić SourceTree jako Administrator przez resztę wieczności.


Nie poleciłbym tego. Otrzymasz jeszcze więcej plików z niepoprawnymi uprawnieniami. Będziesz musiał uruchomić wszystko, co manipuluje plikami repozytorium jako administrator. Czy nie lepiej po prostu naprawić uprawnienia?
David Ferenczy Rogožan

Masz rację. Ale dopiero po tym, jak działał jako administrator, zorientowałem się, że to kwestia pozwolenia. Był to więc krok w mojej procedurze diagnozowania, a nie perfekcyjne rozwiązanie per se.
Lionet Chen,

Pewnie. Ale wielu użytkowników może po prostu wziąć twoją odpowiedź za rozwiązanie, nie wiedząc naprawdę o konsekwencjach. Może lepiej, jeśli dodasz ustalanie uprawnień jako sugerowane rozwiązanie.
David Ferenczy Rogožan

0

Zapisanie konkretnego przypadku, który może powodować ten problem.

Pewnego dnia wypchnąłem gałąź o nazwie „funkcja / podfunkcja”, mając jednocześnie gałąź „funkcja” na pilocie.

Ta operacja działała dobrze bez żadnego błędu po mojej stronie, ale kiedy moi współpracownicy pobrali i / lub wyciągnęli jakąkolwiek gałąź, wszyscy mieli dokładnie ten sam komunikat o błędzie unable to update local ref,cannot lock ref 'refs/remotes/origin/feature/subfeature .

Zostało to rozwiązane poprzez usunięcie featuregałęzi na zdalnym ( git push --delete origin feature), a następnie uruchomienie git remote prune originrepozytorium moich współpracowników, które generowało wiadomości, w tym* [pruned] origin/feature .

Domyślam się, że git fetchpróbowałem wewnętrznie utworzyć subfeatureref w featurefolderze git (.git / ...), ale utworzenie folderu nie powiodło się, ponieważ featureref już był .


0

Ten problem występuje, gdy programista na komputerze Mac utworzył gałąź o nazwie większej niż „>” w nazwie gałęzi.

To spowodowało problemy w TeamCity i na lokalnych komputerach z systemem Windows i systemem SourceTree. BitBucket przepuścił go bez żadnych problemów.

Aby rozwiązać problem, użytkownik usunął gałąź i utworzył ją ponownie. Co było miłe i łatwe.


-1

Miałem tę samą wiadomość, ale z katalogiem, otrzymałem nieudaną wiadomość przy pobieraniu.

git --prone też mi nie pomógł. Okazuje się, że był plik o tej samej nazwie co katalog utworzony zdalnie.

Musiałem przejść do .git \ logs \ refs \ remotes \ origin i skasować plik ustawień regionalnych - a następnie pobrać ponownie, wszystko dobrze.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.