Bitbucket alarmiert, dass mein Git-Repository über 1 GB groß ist. Auf der Repository details -Seite heißt es tatsächlich 1,7 GB . Das ist verrückt. Ich muss große Dateien in die Versionskontrolle aufgenommen haben. Mein lokales Repository ist tatsächlich 10 GB , was bedeutet, dass ich zumindest .gitignore bis zu einem gewissen Grad erfolgreich verwendet habe, um große Dateien von der Versionskontrolle auszuschließen.
Als nächstes folgte ich dem Tutorial hier Ссылка und versuchte unbenutzte große Daten zu löschen. Der Befehl files.git count-objects -v im obersten Ordner meines Repos
gab folgendes zurück:
Das Größenpaket 183607 KB ist viel kleiner als 1,7 GB. Ich war etwas perplex.
Als nächstes habe ich den BFG Repo Cleaner Ссылка heruntergeladen und den Befehl% co_de ausgeführt % im obersten Verzeichnis, um Dateien zu entfernen, die größer als 100 MB sind, aus den letzten Commits. BFG gab jedoch die folgende Meldung zurück:
%Vor%Das Wiederholen desselben für 50M ergab dasselbe.
Bedeutet dies, dass alle Dateien, die größer als 50 MB sind, im letzten Commit sind? Im Source-Code-Browser in Bitbucket habe ich mir Ordner angesehen, die große Datendateien enthalten, aber diese Dateien sind nicht enthalten (erfolgreich ignoriert).
Könnte jemand kurz erklären, was die Ursache für die Größe des Repositorys und das Vorhandensein großer Dateien im Repo ist?
An diesem Punkt müssen Sie sich das Repository auf dem Server ansehen, um sicher zu wissen, was das Problem ist, und Sie werden wahrscheinlich mit dem technischen Support von BitBucket sprechen müssen. Aber Ihre Beschreibung klingt so, als würde Ihr Repository Müll enthalten, der bereinigt werden kann.
Überlegen Sie, ob Sie eine 500-MB-Datei in Ihr BitBucket-Repository hochgeladen haben. Jetzt erkennen Sie Ihren Fehler, und entfernen Sie ihn aus Ihrem Repository in irgendeiner Weise (BFG, zum Beispiel) und drücken Sie diese aktualisierte Referenz. Die Referenz auf Ihrer Fernbedienung wird aktualisiert, um auf die neue Festschreibung zu verweisen, und Ihr Repository wird nicht die große Datei enthalten (wenn Sie Ihr Repository geklont haben, würden Sie die große Datei nicht erhalten).
Aber die Fernbedienung wäre nicht gegangen und hätte das alte Commit oder die alte Datei in diesem Commit gelöscht. Es würde es nur vom Graphen trennen, und diese große Datei wäre nicht länger "erreichbar". Es wäre in der Tat "Müll", der für "Garbage Collection" geeignet wäre. Dies würde die große Datei löschen und Ihre Repository-Größe auf dem Server würde schrumpfen.
Es gibt keine Möglichkeit, den Server nach GC zu fragen (über das git-Protokoll). BitBuckets Unterstützung sollte dies für Sie übernehmen können:
Sie müssen nach uns suchen, um stattdessen den GC auszulösen. Ich denke, der beste Weg ist es zu "eskalieren", wenn es wirklich dringend ist, und wir sollten sofort dazu in der Lage sein. - Bitbucket Support (Dez. 2016)
Beachten Sie, dass dies davon ausgeht, dass Sie das vollständige Repository tatsächlich lokal haben. Stellen Sie sicher, dass Sie fetch --all ausführen, um sicherzustellen, dass Sie lokal keine Untergruppe des (erreichbaren) Verlaufs haben. Im Fall von BFG vergewissern Sie sich, dass Sie Ihr Repository mit der Option --mirror geklont haben.
Wir denken, wir hatten heute das gleiche Problem und konnten es lösen , ohne die Bitbucket-Unterstützung zu kontaktieren , wie unten. Beachten Sie, dass die Methode das letzte Commit aus dem Repo verwirft - damit Sie wahrscheinlich eine Sicherungskopie erstellen möchten.
Bitbucket berichtete, dass unser Repo etwa 2,1 GB betrug, während bei der Clonierung nur etwa 250 MB lokal benötigt wurden. Daraus schlossen wir, dass es wahrscheinlich von großen Dateien in unerreichbaren Commits ist (dank Edwards Antwort oben).
So sehen Sie lokal nicht erreichbare Commits, bei denen die Erreichbarkeit über Reflog nicht berücksichtigt wird:
git fsck --unreachable --no-reflog
Lokal können unerreichbare Commits mit:
bereinigt werden %Vor% Wir können jedoch keinen dieser Befehle remote auf Bitbucket ausführen. Aber, sagen sie auf die Seite über die Verringerung der Repo-Größe (Abschnitt Entfernen Sie die repository limitation ), dass sie git gc selbst als Antwort auf git reset --hard HEAD~1 ausführen (was den letzten Commit verwirft ), gefolgt von git push -f . Außerdem sagen sie im Abschnitt Garbage collection dead data , dass man die Sequenz ausprobieren kann: git reflog expire --expire=now --all , git gc --prune=now , git push --all --force . Angesichts all dessen entschied ich mich, das Folgende lokal zu versuchen, in der Hoffnung, dass es den Reflog löschte und eine Prune lokal schnitt und dann in das entfernte Bitbucket-Repository schob, auf dem es einen gc starten würde:
Das funktionierte, die Repo-Größe ging sofort von 2,1 GB auf ca. 250 MB. :)
Beachten Sie, dass der Zeitparameter ablaufen / ablaufen-unerreichbar / zurückstellen den ablaufenden Abschaltpunkt von jetzt an zurücksetzt. So z.B. "Jetzt" bedeutet alles ablaufen lassen und "30m" bedeutet bis auf Änderungen in den letzten 30 Minuten.
Bearbeiten:
Eine Sache, die mir beim Nachdenken einfällt ist, dass git nach 30 Tagen nicht mehr erreichbar ist. Das funktioniert wahrscheinlich nicht, weil ich git reflog expire , git prune und git gc lokal ausgeführt habe (was wurde vielleicht nicht in den Remote-Repo-Modus versetzt, sondern weil das entfernte git gc ausgelöst durch git reset alle nicht erreichbaren Commits löschte, die älter als 30 Tage waren.
Es könnte also sein, dass das Folgende für mich die gleiche Wirkung gehabt hätte:
%Vor%Und für unerreichbare Änderungen, die in den letzten 30 Tagen vorgenommen wurden, muss ich noch den Bitbucket-Support kontaktieren.
Tags und Links git version-control bitbucket bfg-repo-cleaner