fatal: HEAD konnte nicht als gültige Referenz aufgelöst werden
Lesezeit: 5 Minuten
idurvesh
Ich werde fatal: HEAD konnte nicht als gültige Referenz aufgelöst werden. wann immer ich versuche mich zu binden.
Ich habe versucht
echo ref: refs/heads/master >.git/HEAD
aber es funktioniert nicht
Auch probiert
git commit
Es funktioniert auch nicht aus den folgenden Quellen
Git ‘fatal: No such ref: HEAD’ git tag: fatal: Fehler beim Auflösen von ‘HEAD’ als gültige Referenz
Bitte helfen Sie mit.. Mein gesamter Commit-Verlauf ist ebenfalls verschwunden
was ist die Ausgabe von git branch -v ?
– Ströme
2. Juni 2016 um 14:46 Uhr
Hallo @Flows, es gibt dasselbe “fatal: HEAD konnte nicht als gültige Referenz aufgelöst werden.” Wenn ich es mit git log versuche, ist es fatal: Ihr aktueller Zweig scheint defekt zu sein
– idurvesh
2. Juni 2016 um 14:46 Uhr
Als ich mich im Internet umsah, stellte ich fest, dass dies möglicherweise auf den Berechtigungszugriff zurückzuführen ist. Könnten Sie der 777 Berechtigungen erteilen? .git Ordner rekursiv?
– Ströme
2. Juni 2016 um 14:55 Uhr
Ich denke, der Befehl 777 ist für das Remote-Verzeichnis? Mein Problem ist lokal … bekomme diesen Fehler, wenn ich übertrage ….
– idurvesh
2. Juni 2016 um 15:01 Uhr
Ich weiß, dass das Problem normalerweise im Remote-Repository liegt, aber Sie können das auch in Ihrem lokalen Repository versuchen.
– Ströme
2. Juni 2016 um 15:22 Uhr
Praves Khatri
Ich bin auch auf das gleiche Problem gestoßen und habe es wie folgt gelöst:
Klonen Sie dasselbe Projekt in einen anderen Ordner.
Kopieren Sie die (versteckte) .git Ordner des geklonten Projekts.
Endlich ersetzen .git Ordner des ursprünglichen Projekts mit dem Ordner, den Sie kopiert haben.
Bearbeiten
Warum passiert das?
Beschädigte Git-Repositories sind oft das Ergebnis einer Beschädigung des Dateisystems aufgrund eines plötzlichen Stromausfalls oder anderer Anomalien.
Da git alle Informationen darin speichert .git Ordner und wenn sie beschädigt sind, kann Git das Repository nicht mehr erkennen.
Vorbehalte
Alles in Ihrem vorherigen .git Ordner wird weg sein. Konfigurationen wie Remote-Referenzname(n) muss neu eingerichtet werden.
Das hat tatsächlich auch bei mir funktioniert, ich hatte ein Repo, das zufällig keine Branches mehr finden konnte (nicht einmal master), aber nichts anderes, was ich getan habe (git checkout master, git checkout – usw.), hat funktioniert. Eine so einfache Lösung wie das erneute Klonen und anschließende Kopieren des Git-Ordners hat das Problem behoben. Dadurch konnte ich sogar meine Änderungen beibehalten, sodass ich sie nicht wiederholen musste.
– CDerrig
5. März 2017 um 21:06 Uhr
Wo finde ich den .git-Ordner?
– Andrej Solera
22. Mai 2019 um 4:28 Uhr
@Andrea: Gehen Sie zu Ihrem Anwendungsverzeichnis und geben Sie ein ls -a. Du wirst einen finden.
– Pravesh Khatri
22. Mai 2019 um 7:51 Uhr
Ich habe dieses Problem aufgrund eines Festplattenfehlers. Ich weiß, das ist eine alte Frage, aber vielleicht kann es jemandem helfen. In meinem Fall hatte ich einen lokalen Zweig, an dem ich gearbeitet habe, bevor mein Repo beschädigt wurde, sodass das erneute Klonen des Repos für mich nicht geeignet war. Jede Antwort hier oder in einem anderen Beitrag hat mir geholfen, außer diesem kleinen Stück Code, das ich gefunden habe hier. Ich habe gerade diesen Befehl im Stammverzeichnis meines Repos ausgeführt:
echo ref: refs/heads/master >.git/HEAD
Danach konnte ich ausführen, git branch, git commit und alle anderen git-Befehle.
Ich hoffe, das kann jemandem helfen!
Tut mir leid zu sagen, aber dieses Problem hat die Probleme für mich tatsächlich verschlimmert, jetzt sehe ich: fatal: not a git repository (or any of the parent directories): .git
– mfisher91
22. Januar 2021 um 20:09 Uhr
Mein Problem war mit
git init
git add .
Versucht
git reset
fatal: Failed to resolve 'HEAD' as a valid ref.
git reset --hard
fatal: Failed to resolve 'HEAD' as a valid ref.
Gelöst mit
git rm -r --cached .
Umgebung
Git-Version 1.7.5.4
Ubuntu 11.10
In meinem Fall landete ich bei zwei Zweige mit dem gleichen Namen nach einer Filialumbenennung. Indem Sie einen von ihnen entfernen .git/refs/heads es hat sich alles wieder normalisiert.
Ich hatte dieses Problem nach a Bluescreen des Todes Vorfall – es war also ähnlich wie das, was Sudip Bhandari oben sagte.
Ich habe hineingeschaut .git/refs/heads/<mybranch> und festgestellt, dass der Eintrag beschädigt (unlesbar) war. Diese Datei soll die vollständige Commit-ID des HEAD-Zweigs enthalten.
Ich habe ein neues Repository geklont und kopiert .git/refs/heads/<mybranch> von der neuen Kasse über die beschädigte (ich denke, ich hätte es einfach reparieren können, indem ich eine aktuelle Commit-ID aus Stash oder was auch immer eingefügt hätte).
zurück in das ursprüngliche Repository, tat ich git rm -r --cached . und git reset --hard aufzuräumen und dann festgestellt, dass alles wieder normal war.
Simas Joneliunas
Sichern Sie Ihren vorhandenen .git-Ordner.
Klonen Sie Ihr Projekt aus dem Git-Repository in einen neuen Ordner.
Kopieren Sie .git aus dem neuen Projektordner und ersetzen Sie Ihren ursprünglichen .git-Ordner.
Rocoder
WARUM – fatal: HEAD konnte nicht als gültige Referenz aufgelöst werden?
git ist nicht in der Lage, die Referenz herauszufinden, und dieses Problem kann auftreten, wenn der Referenzkopf beschädigt ist.
Angenommen, Sie haben ursprünglich einen Feature-Branch aus dem Master-Branch ausgecheckt und aufgrund eines Fehlers stoßen Sie auf dieses Problem. Sie können die Referenz der Header-Datei überprüfen, die es sein sollte beschädigt oder kein Wert drin. Idealerweise sollte diese Datei die Hash-Wert übergeben.
cat .git/refs/heads/<my-branch>
LÖSUNG – Das Ersetzen der beschädigten Referenz oder des Referenzwerts löst das Problem.
Gehe zu .git/ref/heads/ und prüfen Sie, ob Sie dort bereits einen Zweig haben, und kopieren Sie den Commit-Hash-Wert in Ihren Zweig.
was ist die Ausgabe von
git branch -v
?– Ströme
2. Juni 2016 um 14:46 Uhr
Hallo @Flows, es gibt dasselbe “fatal: HEAD konnte nicht als gültige Referenz aufgelöst werden.” Wenn ich es mit git log versuche, ist es fatal: Ihr aktueller Zweig scheint defekt zu sein
– idurvesh
2. Juni 2016 um 14:46 Uhr
Als ich mich im Internet umsah, stellte ich fest, dass dies möglicherweise auf den Berechtigungszugriff zurückzuführen ist. Könnten Sie der 777 Berechtigungen erteilen?
.git
Ordner rekursiv?– Ströme
2. Juni 2016 um 14:55 Uhr
Ich denke, der Befehl 777 ist für das Remote-Verzeichnis? Mein Problem ist lokal … bekomme diesen Fehler, wenn ich übertrage ….
– idurvesh
2. Juni 2016 um 15:01 Uhr
Ich weiß, dass das Problem normalerweise im Remote-Repository liegt, aber Sie können das auch in Ihrem lokalen Repository versuchen.
– Ströme
2. Juni 2016 um 15:22 Uhr