Git – “Referenz kann nicht gesperrt werden bei ” auf Git Pull

Ich sehe den folgenden Fehler, wenn ich auf meinem Terminal in intellij git pull mache. Das Projekt wird ständig von mehreren Entwicklern aktualisiert und ich bin mir sicher, dass etwas nicht synchron ist, aber ich kann nicht herausfinden, was das ist.

error: cannot lock ref 'refs/remotes/origin/feature/SOMETHING-1234': is at e131d16d4b4b8c32e3d16d28559baf2e4d18b012 but expected 090916d9bee669944a2ea55703f25a4ebee7d51a
 ! 090916d9b..e131d16d4  feature/SOMETHING-1234 -> origin/feature/SOMETHING-1234  (unable to update local ref)

Was könnte hier das Problem sein? Wie behebe ich das? Der obige Feature-Zweig wurde von einem anderen Entwickler erstellt, den ich nicht löschen möchte.

Hinweis: Dies Ist ein Duplikat, aber die andere Frage hat keine akzeptierte Antwort, also poste ich hier eine. Das Problem tritt auf, weil jemand einen Zweig erstellt hat (feature/SOMETHING-1234 in Ihrem obigen Beispiel), das anders ist nur für den Fall von einem Namen, den Ihr Git bereits aufgegriffen hat. Zum Beispiel haben Sie vielleicht feature/something-1234 oder FEATURE/SOMETHING-1234während sie jetzt haben feature/SOMETHING-1234.

Git glaubt, dass Namen, die sich nur in Groß- und Kleinschreibung unterscheiden, wie z a vs ASind verschiedene Namen. Dies funktioniert korrekt einen Teil der Zeit. Es schlägt auf einigen Betriebssystemen fehl¹ einen Teil der Zeit. Wenn es fehlschlägt – wie es in Ihrem Fall der Fall ist – bekommen Sie seltsame Symptome wie das, das Sie jetzt sehen.

In diesem Fall eine Möglichkeit möglicherweise Abhilfe schafft das Entfernen der (lokalen) Datei .git/refs/remotes/origin/feature/something-1234– Sie können es in Kleinbuchstaben eingeben, unabhängig davon, welche Teile Großbuchstaben enthalten; siehe Fußnote 1 – kurz bevor Sie laufen git fetch. Ihr Git wird dies mit dem von dem anderen Git bereitgestellten Fall neu erstellen. Beachten Sie jedoch, dass das Problem möglicherweise sogar sofort wieder auftreten kann, insbesondere wenn das andere Git eines davon ist dürfen speichern beide Namen (z. B. beides feature/something-1234 Und feature/SOMETHING-1234) jederzeit.

Um das Problem dauerhafter zu heilen, ist es notwendig löschen der Duplikat-ausgenommen-für-Fall-Name in der andere Git. Das heißt, wenn ein GitHub-Git Branches mit dem Namen both hat feature/SOMETHING-1234 Und feature/something-1234, müssen Sie und Ihre Kollegen sich zusammensetzen und einigen, welcher dieser beiden Namen beibehalten und welcher gelöscht werden soll. Dann können und sollten Sie die “falsche” löschen und sicherstellen, dass Sie sie niemals neu erstellen.

(Ich denke, es gibt fortlaufende Arbeiten in Git, die dieses Problem für alle beheben werden, aber es ist noch nicht veröffentlicht.)

¹Technisch gesehen ist dies eine Dateisystemspezifisches Problem heutzutage eher als ein betriebssystemspezifisches Problem. Es tritt jedoch normalerweise auf Windows- und MacOS-Dateisystemen auf, die so eingerichtet sind, dass sie die Groß- und Kleinschreibung beibehalten, aber die Groß- und Kleinschreibung falten. Das heißt, wenn Sie eine Datei mit dem Namen erstellen ReadMeund bitten Sie dann das System, eine Datei mit dem Namen zu öffnen readme oder READMEes öffnet das Vorhandene ReadMe Datei.

Andere Dateisysteme – einschließlich der üblichen, die auf Linux-Hosts verwendet werden, z. B. solche, auf denen GitHub ausgeführt wird – behandeln readme, ReadMeUnd README als drei verschiedene Dateien. Diese Systeme können und werden also alle drei Dateien gleichzeitig speichern. Die Falldateisysteme klappen unter Windows und MacOS buchstäblich zusammen kippen Speichern Sie drei solcher Dateien.

Git verwendet derzeit ein hybrides Schema, in dem Refs oder Verweise– Verzweigungs-, Tag- und andere Namen – werden an einem oder beiden von zwei Orten gespeichert: einer einfachen Klartext-Tabellendatei, die jede Referenz in einer Zeile zusammen mit ihrer Hash-ID enthält, oder eine Hash-ID pro Datei mit der Datei Name passend zum Referenznamen. Wenn sich die Referenzen nur in Groß- und Kleinschreibung unterscheiden, funktioniert der Speichermechanismus pro Datei nur auf Dateisystemen korrekt, die beide Namen speichern können. Der One-Big-File-Mechanismus funktioniert jedoch auch auf dem üblichen Windows- und MacOS-Dateisystem korrekt, da sich alle Einträge nur in einer Datei mit dem Namen befinden .git/packed-refs.

Beachten Sie, dass, wenn ein Verweis in beiden erscheint .git/packed-refs Und eine einzelne Datei, die Version der einzelnen Datei überschreibt die .git/packed-refs Ausführung.

Ich habe das Terminal geöffnet und verwende den folgenden Befehl und funktioniert für mich. Nachdem Sie diesen Befehl geschrieben haben, werden alle Zweige ohne Fehler gezogen

git remote prune origin