Repozytorium Git zostało uszkodzone po śmierci komputera

95

Mój komputer zepsuł się i teraz jedno z moich repozytoriów git jest zepsute. Kiedy próbuję przejść do kasy, mówi mi:

warning: ignoring broken ref refs/heads/master.
error: Your local changes to the following files would be overwritten by checkout:
        com.vainolo.jdraw2d.releng.p2/pom.xml
Please, commit your changes or stash them before you can switch branches.
Aborting

Kiedy wykonuję git stash, otrzymuję:

fatal: bad revision 'HEAD'
fatal: bad revision 'HEAD'
fatal: Needed a single revision
You do not have the initial commit yet

Więc co mogę zrobić?

Aktualizacja danych wyjściowych git reflog:

fatal: bad default revision 'HEAD'

Niezbyt obiecujące ... Wynik git fsck:

error: Invalid HEAD
Checking object directories: 100% (256/256), done.
error: unable to unpack 59551f96b4e87a1c14293c19eb548ce6fa1f196f header
error: inflateEnd: stream consistency error (no message)
fatal: loose object 59551f96b4e87a1c14293c19eb548ce6fa1f196f (stored in .git/objects/59/551f96b4e87a1c14293c19eb548ce6fa1f196f) is corrupt
vainolo
źródło
Czy możesz sprawdzić, czy .git/refs/heads/masteristnieje i czy jego zawartość jest poprawnym hashem commita twojego repozytorium (możesz to sprawdzić np. Używając git show <hash>)?
poke
Wiem, że to oczywiste, ale nadal pytam - czy masz jakieś zdalne repozytoria tego samego repozytorium git?
Tuxdude
@poke zawartość .git/refs/heads/master/jest kilka^@
vainolo
@Tuxdude tak, ale nie zaktualizowane do moich najnowszych zmian
vainolo
1
Co git reflogci powie? Próbowałeś biegać git fsck?
kynan

Odpowiedzi:

175

Udało mi się dojść do siebie poprzez:

rm .git/refs/remotes/origin/HEAD
git fetch --all
jfrumar
źródło
W moim przypadku stało się tak, ponieważ usunąłem niektóre gałęzie lokalne i zdalne (jakoś plik .git / refs / remotes / origin / HEAD pozostał w stanie niespójnym). Zmiana zawartości powyższego pliku tak, aby wskazywała na istniejący oddział lokalny (np. Ref: refs / remotes / origin / master) rozwiązała ten problem. Mimo to powyższe podejście może być lepsze, ponieważ HEAD może wskazywać na zatwierdzenie spoza bieżącej gałęzi.
crissdev
W przypadku, gdy problem dotyczy określonego modułu podrzędnego git, pierwsze polecenie zmienia się nieznacznie narm <root repository path>/.git/modules/<path to the submodule>/refs/remotes/origin/HEAD
Gobe.
1
Musiałem zrobić rm -rf .git/refs/remotes/origin, ale wskazałeś mi właściwy kierunek
Jacka
24

Zacznij od wykonania czynności sugerowanych w sekcji Odzyskiwanie uszkodzonego repozytorium git :

  • sprawdź, czy .git/refsnadal zawiera coś przydatnego
  • sprawdzić git reflogi nie sprawdzić , czy zawartość .git/logs/refs/heads/mastergałęzi, w której byłeś, była ostatnia
  • uruchomić git fsck, potencjalnie z --unreachablelub--lost-found

Miejmy nadzieję, że pozwoli ci to dowiedzieć się, jaki masterpowinien być ref, abyś mógł go przywrócić (tj. Zakotować poprawny SHA1 do .git/refs/heads/master).

W przypadku, gdy jakikolwiek obiekt zawarty w tym zatwierdzeniu jest rzeczywiście uszkodzony, HEADniestety nie można go przywrócić . Zakładając, że twoje drzewo robocze i / lub indeks są nienaruszone, możesz wypróbować git reset --soft(lub nie powiedzie się to a git reset) poprzedniego zatwierdzenia, a następnie ponownie wykonać zatwierdzenie. Unikaj operacji, które zmieniają twoje drzewo robocze sa git checkout -flub git reset --hard.

kynan
źródło
Spojrzałem na .git/logs/refs/heads/mybranch. Pokazuje jakąś historię zatwierdzeń w tej gałęzi. Przeglądając to, wybrałem SHA i próbowałem je wyświetlić git show. (Każde zatwierdzenie ma dwa SHA, wybrałem drugi, tuż przed nazwiskiem autora). Ostatni był uszkodzony, ale poprzedni mógł być git shown, a następnie mogłem go wcisnąć git push origin abcdef:mybranch.
Ed Avis
13

Miałem podobny problem po niebieskim ekranie śmierci w systemie Windows 8.1

Miałem plik w tej lokalizacji ...

C:\www\<project>\.git\refs\remotes\origin\<problem-branch>

I był pusty, podczas gdy inne pliki gałęzi w tym folderze mają w sobie długie ciągi.

NB nie miałem żadnych zmian / zatwierdzeń

  • Zrobiłem kopię zapasową <problem-branch>pliku
  • Usunięto plik
  • git fetch --all ponownie zdobyć gałąź

Następnie automatyczne uzupełnianie kart ponownie zaczęło działać

Carlton
źródło
6

Jeśli nie ma wielu zmodyfikowanych plików, myślę, że wygodnym sposobem rozwiązania tego problemu jest:

  1. wykonaj kopię zapasową plików zmodyfikowanych w repozytorium
  2. usuń istniejące repozytorium
  3. sklonuj go ponownie z serwera
  4. wklej pliki z kroku 1 do repozytorium i git commit -a
alsotang
źródło
tak, nikt nie mógł myśleć o ponownym klonowaniu. świetna sugestia
Selman Genç,
5

Udało mi się to rozwiązać, usuwając główny plik w katalogu git \ refs \ heads

Manos Gaitanakis
źródło
To pomogło, usunęło gałąź z mojej listy na intellij i sprawdziłem ją jako nową gałąź. Na szczęście wprowadziłem zmiany, więc wszystkie były dostępne.
OAM
4

Po zamrożeniu komputerowej i katastrofy, mój git oddział został uszkodzony z komunikatem: git fatal: your current branch appears to be broken. Nic nie mogłem zrobić.

Po wykonaniu git fscktej czynności wspomniałem, że gałąź ma rozszerzenie error: Invalid HEAD. refs/heads/<branch>miał invalid sha1 pointer.

Po skorzystaniu z opcji tutaj, otworzyłem .git/refs/heads/<branch>w edytorze notepad ++ i każdy ze znaków sha1 był NUL.

Na szczęście potrzebowałem tylko zresetować gałąź do stanu zdalnego, a to było na repozytorium bitbucket. Złapałem sha1 z końcówki zdalnego repozytorium i skopiowałem do .git/refs/heads/<branch>zapisanego, a następnie zrobiłem git reset --hard HEADi wszystko wróciło do normy.

j4v1
źródło
2

Byłem na tyle głupi, że zapomniałem push, a mój komputer się zawiesił podczas wykonywania zatwierdzenia. Mogłem odzyskać wszystko oprócz ostatniego zatwierdzenia, otwierając .git / logs / refs / heads /

Ten plik zawiera wszystkie zatwierdzenia (wraz z ich SHA) do gałęzi, co zrobiłem, aby odzyskać:

  • Utwórz kopię zapasową ostatnich zmian w folderze tymczasowym
  • przejdź do „czystego konta”
    • git checkout master
    • git reset --hard
  • sprawdź przedostatnią zmianę w dzienniku
  • utwórz gałąź z tej odłączonej głowy
  • PCHAĆ
  • Przywróć najnowsze zmiany
  • Zatwierdź ponownie

Więc nawet jeśli popełnisz głupi błąd, nie cofnie Cię od razu cały dzień pracy z gitem :)

Markus Palcer
źródło
2

Nie mogłem wyewidencjonować mojej gałęzi głównej z powodu błędu nie można zablokować ref. Skończyło się na usunięciu: .git/refs/remotes/origin/HEAD .git/refs/remotes/origin/master

i wywołując to polecenie git:

git fetch --all
Keon Sadatian
źródło
1

Wiem, że to za późna odpowiedź, ale otrzymywałem ten błąd, ponieważ nie miałem pliku origin/head. Możesz się tego dowiedzieć, biegając git branch -r. Jeśli nie widzisz swojego origin/headwskazania na zdalne źródło, możesz to ustawić, uruchamiając git remote set-head origin {{your branch name}}.

Teraz biegnij git branch -rponownie i powinieneś zobaczyć coś takiego: origin/HEAD -> origin/develop

Mam nadzieję, że pomoże to każdemu, kto napotka ten problem.

aaronwbrown
źródło
1

Mój komputer zawiesił się dwa razy, w wyniku czego moje repozytorium git zostało zepsute lokalnie. Nie mogłem wyciągnąć zmian, poprosił o ustawienie zdalnego pochodzenia, ale nie działało w gitKraken.

W wierszu polecenia otrzymywałem ten błąd wprowadź opis obrazu tutaj

Wiedziałem, że moje referencje są zepsute i należy je naprawić. Musiałem zrobić git bash (w SourceTree kliknij „terminal”). Następnie przejdź do folderu referencyjnego, takiego jak ten

cd .git
cd refs
cd remotes
cd origin

będzie tam nazwa pliku master, użyj, lsaby zobaczyć, co jest w katalogu. Następnie po prostu usuń go za pomocą rm master

bam, uszkodzony plik zniknął. Teraz, jeśli wydasz polecenie git branch -a, wypisze to

$ git branch -a
* master
  remotes/origin/master (this in red color -scary :) )

Następnie wydaj to polecenie, a naprawi ono odniesienia

$ git remote set-head origin master

Podsumowując, jeśli spróbujesz wyciągnąć pilota, powinien wyświetlić pustą nazwę pilota, która została naprawiona.

wprowadź opis obrazu tutaj

Hammad Khan
źródło
0

Miałem ten sam problem, ale nie miałem szczęścia, nie mogłem rozwiązać problemu. Odsunąłem repozytorium na bok, ponownie sklonowałem to z serwera i próbowałem połączyć je. Oczywiście pokazało wiele plików niezwiązanych z moją gałęzią, ale pomaga wyodrębnić wymagane pliki.

Samuelens
źródło
0

Sprawdź, czy MSWindows utworzył pliki desktop.ini, które jednocześnie korzystają z git? dla mnie to robi. Po usunięciu ich wszystkich w podfolderach katalogu .git to działa.

Vinnief
źródło
0

Miałem ten sam problem, gdy Android Studio nagle się wyłączyło (z powodu utraty zasilania komputera).

Rozwiązałem to, kopiując zawartość mojego C:\Users\myusername\AndroidStudioProjects\MyBrokenApp\.git\refs\heads\masterpliku do mojego C:\Users\myusername\AndroidStudioProjects\MyBrokenApp\.git\refs\remotes\origin\masterpliku.

(Wcześniej włączałem również opcję „Wymuś wypychanie” w Android Studio, ale nie sądzę, aby był to konieczny krok).

Uwaga:

Znalazłem to rozwiązanie, porównując zawartość plików w moim C:\Users\myusername\AndroidStudioProjects\MyBrokenApp\.git\katalogu (w tym podkatalogach) z odpowiadającymi im plikami w innym zdrowym projekcie - np C:\Users\myusername\AndroidStudioProjects\MyHealthyApp\.git\..

Możesz mieć inny plik, który jest uszkodzony, ale porównując z innym sprawnym projektem, powinieneś być w stanie szybko wykryć, co jest nie tak.

Jeśli nie masz innego zdrowego projektu, w którym skonfigurowano git, warto utworzyć prosty w taki sam sposób, w jaki utworzyłeś uszkodzony projekt, aby można było zbadać, porównać i naprawić itp.

PS - Mój komunikat o błędzie (edytowany) to: warning: ignoring broken refs/remotes/origin/master.fatal bad revision 'refs/remotes/origin/master..refs/heads/master' during executing git -c core.quotepath=false log refs/remotes/origin/master..refs/heads/master --pretty=format --encoding=UTF-8 -M --name-status -c --

zakaz geoinżynierii
źródło
0

Wybacz, żebym powtórzył za kimś (nie przeczytałem wszystkich opinii). Moim zdaniem najprostszym sposobem rozwiązania problemu jest skopiowanie projektu bez .git i .idea, wyczyszczenie go, sklonowanie z gita, usunięcie wszystkiego oprócz powyższych katalogów, a następnie wklejenie poprzedniej kopii do nowo utworzonego repozytorium z .git i .idea . Mam nadzieję, że to ma sens.

Andrey Sulay
źródło