Kann nicht auf GitHub pushen, weil eine große Datei vorhanden ist, die ich bereits gelöscht habe

Question

Aktuell habe ich

1. Leeres GitHub-Repository
2. SSH-Server-Repository (Hauptrepository)
3. Lokales Repo

Das SSH-Server-Repository war das aktuellste Repository (Produktionsseite), also habe ich von dort aus ein Git clone auf das lokale Repository durchgeführt. Anschließend habe ich versucht, ein git push zu GitHub zu machen.

Alles lief gut, aber dann kam eine Meldung, dass die Datei filename.gz für GitHub zu groß sei. Da ich diese Datei nicht brauchte, habe ich mehrere Git-Befehle ausgeführt, um sie aus dem Git-Cache zu entfernen, und dann zurück auf den SSH-Server gepusht.

Ich sehe die große Datei lokal nicht, aber sie ist immer noch auf dem SSH-Server, obwohl git diff nichts zurückgibt und git push "Alles ist auf dem neuesten Stand" zurückgibt - und obwohl die Datei im lokalen Repository nicht sichtbar ist. Beim Versuch, zu GitHub zu pushen, erhalte ich immer noch einen Fehler.

remote: Fehler: Die Datei fpss.tar.gz ist 135,17 MB groß; das übersteigt das Dateigrößenlimit von GitHub von 100 MB

Ich habe die Schritte unter "Problembehebung" auf der GitHub-Hilfeseite befolgt, sollte das nicht ausreichen?

Warum ist die Datei immer noch "in der Luft", wenn sie weder lokal ist noch in git status/diff/push aufgelistet ist?

Answer 1

Ich hatte ein ähnliches Problem und habe den obigen Schritt verwendet, um die Datei zu entfernen. Es hat perfekt funktioniert.

Dann habe ich einen Fehler bei einer zweiten Datei bekommen, die ich entfernen musste: remote: error: Datei ist 109,99 MB; das überschreitet das Dateigrößenlimit von GitHub von 100,00 MB

Ich habe den gleichen Schritt versucht, aber einen Fehler erhalten: "Eine vorherige Sicherung existiert bereits in "

Aus der Recherche auf dieser Website habe ich den Befehl verwendet: git filter-branch --force --index-filter "git rm --cached --ignore-unmatch " --prune-empty --tag-name-filter cat -- --all

Es hat super funktioniert und die großen Dateien wurden entfernt.

Unglaublicherweise ist der Push immer noch mit einem anderen Fehler fehlgeschlagen: Fehler: RPC fehlgeschlagen; curl 56 OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104 fatal: Das entfernte Ende hat unerwartet aufgelegt

Dies habe ich behoben, indem ich die .git-Konfigurationsdatei direkt geändert habe - postBuffer = 999999999

Danach hat der Push funktioniert!

Answer 2

Ich habe alle obigen Methoden ausprobiert, aber keine davon hat für mich funktioniert.

Dann kam ich auf meine eigene Lösung.

1. Zunächst benötigen Sie einen sauberen, aktuellen lokalen Repository. Löschen Sie alle großen Dateien.

2. Erstellen Sie jetzt einen neuen Ordner AUßERHALB Ihres Repository-Ordners und verwenden Sie "Git Repository hier erstellen", um daraus ein neues Git-Repository zu machen, nennen wir es neues_lokales_repo. Das ist es! Alle obigen Methoden sagten, dass Sie den Verlauf löschen müssen..., nun, ich habe genug davon, lassen Sie uns ein neues Repository erstellen, das überhaupt keinen Verlauf hat!

3. Kopieren Sie die Dateien aus Ihrem alten, durcheinandergebrachten lokalen Repository in das neue, schöne Repository. Beachten Sie, dass das grüne Logo auf dem Ordnersymbol verschwinden wird, das ist vielversprechend, denn es handelt sich um ein neues Repository!

4. Committen Sie auf den lokalen Branch und pushen Sie dann zum entfernten neuen Branch. Nennen wir ihn neuer_remote_branch. Wenn Sie nicht wissen, wie man von einem neuen lokalen Repository pusht, googeln Sie es.

5. Gratulation! Sie haben Ihren sauberen, aktuellen Code auf GitHub gepusht. Wenn Sie den entfernten Master-Branch nicht mehr benötigen, können Sie Ihren neuen_remote_branch als neuen Master-Branch festlegen. Wenn Sie nicht wissen, wie das geht, googeln Sie es.

6. Letzter Schritt, es ist Zeit, das durcheinandergebrachte alte lokale Repository zu löschen. In Zukunft verwenden Sie nur noch das neue_lokales_repo.

Answer 3

Ich hatte dasselbe Problem und keiner der Antworten hat bei mir funktioniert. Ich habe es durch die folgenden Schritte gelöst:

1. Finde heraus, welcher Commit(s) die große Datei enthält

git log --all -- 'large_file`

Der unterste Commit ist der älteste Commit in der Ergebnisliste.

2. Finde den Commit direkt vor dem ältesten.

git log

Annehmen, du bekommst:

commit 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32

3. Git Rebase

git rebase -i 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32

Tips:

1. Listenelement
2. Ich habe einfach drop für die Commits ausgewählt, die die große Datei enthalten.
3. Es kann während des Rebasing zu Konflikten kommen. Diese lösen und git rebase --continue verwenden, um fortzufahren, bis du fertig bist.
4. Wenn beim Rebasing etwas schief geht, verwende git rebase --abort, um es abzubrechen.

Answer 4

git lfs migrate import --include="fpss.tar.gz"

dies sollte Ihre lokalen Commits mit den neuen lfs refs überschreiben

https://github.com/git-lfs/git-lfs/blob/master/docs/man/git-lfs-migrate.1.ronn?utm_source=gitlfs_site&utm_medium=doc_man_migrate_link&utm_campaign=gitlfs#examples

Answer 5

Die Lösung, um die großen Dateien/Ordner innerhalb des Arbeitsverzeichnisses zu behalten

Dies ist die Zeile, die das Problem gelöst hat, das hier gestellt wurde (aus Antwort 1):

git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch ' HEAD

Dieser Befehl löscht auch die Datei/den Ordner, wenn sich die Datei/der Ordner im Arbeitsverzeichnis befindet.

Wenn Sie die Datei/den Ordner im Arbeitsverzeichnis behalten möchten, schlage ich die folgenden Schritte vor.

1. Nach diesem Fehler führen Sie git reset HEAD^ aus

2. Fügen Sie die betreffende Datei/den betreffenden Ordner in die ``.gitignore``-Datei ein.

3. Fahren Sie wie gewohnt fort git add ., was möglicherweise andere Dateien/Ordner erfasst, aber die .gitignore-Datei erfassen muss. Als nächstes git commit -m"Nachricht" und schließlich git push origin