Im Repository ist bereits eine Sperrdatei vorhanden, die den Abschluss dieses Vorgangs blockiert

Ich arbeite an einem ASP.NET Core-Projekt. Ich versuche zu push ein Commit zu meinem Branch mit GitHub Desktop. Aber jedes Mal, wenn ich versuche zu committen, erhalte ich diesen Fehler:

Im Repository ist bereits eine Sperrdatei vorhanden, die den Abschluss dieses Vorgangs blockiert.

Beim Durchsuchen des Internets ist die einzige Lösung, die ich gefunden habe, das Löschen index.lock Datei drin .git Ordner manuell.

Aber wenn ich diese Datei lösche, erscheint sie jedes Mal wieder, wenn ich versuche, sie zu übernehmen, was es mir unmöglich macht, sie zu übernehmen. Ich habe bereits versucht, von Visual Studio aus zu committen, aber es ist auch fehlgeschlagen.

Kann mir jemand helfen?

das ist mir auch passiert, lösche einfach die genannte Datei index. lock die sich im git-Ordner befindet. Nachdem Sie es gelöscht haben, versuchen Sie, es erneut zu übertragen. es hat mein Problem gelöst

• Schritt 1: Gehen Sie zum gewünschten Ordner
• Schritt 2: Gehen Sie zu den Ordneroptionen
• Schritt 3: Aktivieren Sie „Versteckte Dateien/Ordner anzeigen“.
• Schritt 4: Es wird Ihnen ein Git-Ordner angezeigt, gehen Sie einfach und löschen Sie die index.lock-Datei von dort und Sie können erneut einen Commit durchführen.

Git verwendet index.lock um zu wissen, dass irgendein Git-Prozess – vielleicht dieser, wenn er gerade erstellt wurde index.lock selbst oder vielleicht ein anderer Git-Prozess – ist damit beschäftigt, Dinge mit dem Repository zu tun, die das Sperren des Index von Git erfordern. Wenn ein Git diese Sperrdatei erfolgreich erstellt, geht es seiner Arbeit nach und aktualisiert verschiedene interne Datenbanken, bis es fertig ist. Es dann löscht diese Sperrdatei, um anzuzeigen, dass es fertig ist, und andere Git-Befehle können jetzt beginnen, ihre Aufgaben erledigen und beenden.

Wenn da ein … ist Insekt In Ihrem Git-System ist es möglich, einen Git-Befehl zu erstellen index.lock, beginnt mit seiner Arbeit und stürzt dann ab, wobei die Sperrdatei zurückbleibt. In diesem Fall ist es richtig, auf ein nicht fehlerhaftes Git zu aktualisieren, damit das Problem nicht erneut auftritt, und auch das zu entfernen index.lock Datei. (Sie können dies in beliebiger Reihenfolge tun, aber wenn der Fehler bestehen bleibt, hinterlassen einige Git-Befehle möglicherweise die falsche Sperre.) Aufgrund einer ziemlich umfangreichen Testsuite ist diese Art von Fehler heutzutage selten in Git – im schlimmsten Fall Früher war es häufiger, aber jetzt sollte es kaum noch vorkommen.

Wenn dein Computer selbst stürzt ab (aufgrund eines Nicht-Git-Fehlers, eines Stromausfalls oder was auch immer) während Git mitten in einer dieser Operationen ist, ist es möglich, dass Git nie die Chance bekommt, die zu entfernen index.lock Datei. In diesem Fall müssen Sie nur die entfernen index.lock Datei manuell. Doch nach einem Computerabsturz andere Teile der internen Datenbanken von Git könnten durch den Absturz beschädigt worden sein, daher ist es ratsam, es auszuführen git fsck. Der git fsck Das Programm gibt sogar auf gesunden Systemen eine Reihe von Meldungen aus, seien Sie also nicht allzu beunruhigt über verschiedene “Dangling Commit”- oder “Dangling Blob”-Meldungen: Diese sind nur informativ. (Im Allgemeinen und idealerweise sollte Ihr Computer selbst niemals abstürzen und Ihre Stromversorgung sollte niemals ausfallen, und die Menschen sollten im Februar 2021 in Texas nicht erfroren sein, aber die Welt ist nicht immer ideal.)

(Windows-Systeme sehen manchmal ein schlechtes Verhalten einiger Antivirensoftware. Dies kann in einigen Fällen von selbst verschwinden. Ich meide Windows, daher habe ich hier keine spezifischen Empfehlungen außer „Windows vermeiden“.)

Schließlich gibt es noch ein Problem, das in letzter Zeit für einige Leute zu einem häufigen Problem geworden ist, weil Cloud Storage so attraktiv ist.¹ Insbesondere wenn Sie ein Git-Repository (die .git Verzeichnis) in einer Art Cloud-Speichersystem oder sogar in einer Einrichtung mit gemeinsam genutztem Datenträger oder gemeinsam genutztem Dateisystem über eine virtuelle Maschine, die Wettbewerb zwischen verschiedenen Agenten, die versuchen, diesen Speicherbereich zu synchronisieren, kann Ihr Git-Repository beschädigen, einschließlich der Wiederbelebung von Fälschungen index.lock Dateien oder sogar die internen Datenbanken von Git beschädigen. Tun Sie dies nicht! Behalten Sie das Git Repository in einem nicht freigegebenen lokalen Festplattenbereich.

¹Naja, zumindest oberflächlich. Es gibt wirklich Vorteile, aber ich persönlich abonniere die Lamport-Definition eines verteilten Systems: Ein verteiltes System ist ein System, bei dem der Ausfall eines Computers, von dem Sie nicht einmal wussten, dass er existiert, Ihren eigenen Computer unbrauchbar machen kann.

Der index.lock Datei immer wieder angezeigt, da sie entweder von GitHub Desktop oder einem anderen Programm (z. B. Visual Studio) oder Prozess noch verwendet wird.

In seltenen Fällen könnte dies ein Fehler in Ihrem Git sein.

Falls Sie den Übeltäter nicht einfach identifizieren und das Wiederauftauchen-Verhalten verhindern können, sollten Sie einen Neustart Ihres Computers in Betracht ziehen und dann die löschen index.lock Datei, bevor Sie GitHub Desktop und/oder Ihr Visual Studio starten.

Als Alternative können Sie Folgendes in Betracht ziehen:

• Stash-Änderungen,
• Wechseln Sie in eine andere Filiale,
• Zurückgehen,
• Trage Stash auf und
• Drücken Sie erneut.

Es gibt einen Ordner namens HEAD.lock in deinem Git-Ordner.
Löschen und versuchen Sie es erneut. das ist Arbeit für mich