So verkleinern Sie den .git-Ordner

134

Meine aktuelle Basis hat eine Gesamtgröße von ca. 200 MB.

Aber mein .git-Ordner hat eine erstaunliche Größe von 5 GB (!). Da ich meine Arbeit auf einen externen Server übertrage, brauche ich keine große lokale Historie ...

Wie kann ich den .git-Ordner verkleinern, um Speicherplatz auf meinem Notebook freizugeben? Kann ich alle Änderungen löschen, die älter als 30 Tage sind?

Vielen Dank für jede Hilfe :)

git

— JMW
quelle

2

Können Sie die Ausgabe von posten git count-objects -v?

— CB Bailey

2

Mögliches Duplikat von Reduzieren der Größe

— SDS

113

Sie sollten nicht alle Änderungen löschen, die älter als 30 Tage sind (ich denke, es ist irgendwie möglich, Git auszunutzen, aber wirklich nicht empfohlen).

Sie können aufrufen git gc --aggressive --prune, wodurch die Speicherbereinigung in Ihrem Repository durchgeführt und alte Objekte entfernt werden. Haben Sie viele Binärdateien (Archive, Bilder, ausführbare Dateien), die sich häufig ändern? Diese führen normalerweise zu riesigen .git-Ordnern (denken Sie daran, dass git Snapshots für jede Revision speichert und Binärdateien schlecht komprimiert werden).

— stricken
quelle

32

Eigentlich git gc --aggressivegilt das als schlechte Praxis. Es ist besser zu benutzen git repack -a -d --depth=250 --window=250.

— Artefakt2

18

@knittl: absolut. Hier ist eine Nachricht von Linus selbst: gcc.gnu.org/ml/gcc/2007-12/msg00165.html

— Artefact2

3

@ artefact2: danke für den link! Ich habe es gelesen und Linus weist darauf hin, dass - aggressiv wird (gute) Deltas nicht wiederverwenden - die in dieser Frage anscheinend nicht existieren, weil das Repository riesig ist. Das Umpacken wird tatsächlich viel länger dauern. git gc --aggressiveruft repack mit einer Fenstergröße von 250 (vgl. manpage) und einer Tiefe von 250 (vgl. Quellcode) auf. --aggressive fügt zusätzlich den -fSchalter hinzu, um alle vorherigen Delta-Operationen wegzuwerfen und zu wiederholen (wie auch im Link erwähnt)

— knittl

1

Ich habe gerade das Repo von hg.nginx.org/nginx (RELEASE-1.4.0 ist Tipp) mit git-remote-hg ausgecheckt und dies ergab ein Repo von ungefähr 100 MB. Mit git gc --aggressive --prunehat dies auf 19 MB reduziert.

— Lekensteyn

15

@ Artefact2 Ihre Aussage ist veraltet : Beachten Sie, wie alt dieser Beitrag ist. Tatsächlich führte die Diskussion auf der Mailingliste am selben Tag, an dem sie veröffentlicht wurde, zu diesem Commit: [..] Daher sind die Verpackungsparameter heutzutage für beide Methoden gleich. . --pruneist auch nicht erforderlich, da es seitdem zum Standard wurde v1.5.5-rc0(Commit 25ee973 , März 2008).

— Lekensteyn

68

Hier ist, was der Schöpfer von Git Linus zu sagen hat, wie Sie Ihr Git-Repo verkleinern können:

Das Äquivalent von "git gc --aggressive" - aber * richtig * gemacht - ist (über Nacht) so etwas zu tun
   git repack -a -d --depth=250 --window=250
Bei dieser Tiefe geht es nur darum, wie tief die Delta-Ketten sein können (verlängern Sie sie für die alte Geschichte - es ist den Platzaufwand wert), und bei der Fenstersache geht es darum, wie groß ein Objektfenster ist, das jeder Delta-Kandidat scannen soll.

Und hier möchten Sie vielleicht das "-f" -Flag hinzufügen (das ist "Alle alten Deltas löschen", da Sie jetzt tatsächlich versuchen, sicherzustellen, dass dieser tatsächlich gute Kandidaten findet.

Quelle: http://gcc.gnu.org/ml/gcc/2007-12/msg00165.html

Werden dadurch Binärdaten entfernt, die in meinem Repo verwaist sind? "git repack" entfernt keine Bilder oder Binärdaten, die Sie in Ihr Repo eingecheckt und dann gelöscht haben. Um diese Art von Daten dauerhaft aus Ihrem Repo zu löschen, müssen Sie Ihren Verlauf neu schreiben. Ein häufiges Beispiel dafür ist, wenn Sie versehentlich Ihre Passwörter in git einchecken. Sie können zurückgehen und einige Dateien löschen, aber dann müssen Sie Ihren Verlauf von damals bis heute neu schreiben und dann Push und dann neues Repo an Ihren Ursprung erzwingen.

— David Dehghan
quelle

Für mich ist der .git-Ordner ungefähr 1.5G. Ich habe es versucht, aber ich habe folgenden Fehler erhalten. fatal: Out of memory, malloc failed (tried to allocate 39763130 bytes)

— Miron

2

repackWird der Shrink nach der lokalen Ausführung , einem Commit und einem Push auch remote ausgeführt?

— Timo

@ David Dehghan: Hey, ich habe es aus dem Projektverzeichnis versucht, aber die Größe des .git-Ordners hat sich nicht geändert. Wird dies erwartet oder muss ich Druck machen, um die Änderungen zu sehen? (Entschuldigung, nicht sehr erfahren mit Git.) Ich habe ein Bild / GIF im Repo und ich habe mehrere verschiedene Versionen dieses Bildes festgeschrieben und ich nehme an, dass sich die Größe von Git erhöht hat.

— Giorgim

Hallo, leider bereinigst du jetzt so die alte Binärversion. Dazu müssen Sie Ihre Geschichte neu schreiben, was eigentlich kompliziert ist. Hier ist ein Hinweis

— David Dehghan

22

Ich habe es versucht, aber mein Repository war immer noch sehr groß. Das Problem war, dass ich versehentlich einige generierte große Dateien eingecheckt hatte. Nach einigem Suchen habe ich ein großartiges Tutorial gefunden, das es einfach macht, die großen generierten Dateien zu löschen. Mit diesem Tutorial konnte ich mein Repository von 60 MB auf <1 MB verkleinern.

Steve Lorek, So verkleinern Sie ein Git-Repository

— Chris Hinshaw
quelle

4

Hier ist eine archivierte Version für den Fall von Link Rot. Diese Antwort ist / war hilfreich für ein Repo, bei dem .exe- und .zip-Dateien festgeschrieben wurden, die die Größe des .git-Ordners

— aufblähten

9

5 GB vs 200 MB sind irgendwie komisch. Versuche zu rennen git gc.

Aber nein, wenn Sie Ihr Repository nicht in Module aufteilen, können Sie die Größe des .gitVerzeichnisses nicht verringern .

Jeder Klon eines Git-Repos ist ein vollwertiges Repository, das als Server fungieren kann. Das ist das Grundprinzip der verteilten Versionskontrolle.

— Šimon Tóth
quelle

3

Ich verwende git eher als Synchronisationsmechanismus als für den Versionsverlauf. Meine Lösung für dieses Problem bestand darin, sicherzustellen, dass alle meine aktuellen Quellen in einem zufriedenstellenden Zustand sind, und dann einfach .git zu löschen und die Repos neu zu initialisieren. Speicherplatzproblem behoben. :-) Verlauf weg :-( Ich mache das, weil mein Repo auf einem kleinen USB-Stick ist. Ich möchte oder brauche nicht meinen gesamten Verlauf. Wenn ich eine Methode hätte, um nur den Verlauf abzuschneiden, würde ich das verwenden.

Wenn ich daran interessiert wäre, meinen Verlauf zu behalten, würde ich das aktuelle Repository archivieren. Irgendwann später könnte ich das ursprüngliche Repository klonen und alle Änderungen aus dem neuen Repo kopieren (nehmen wir an, ich habe nicht viel (irgendwelche) umbenannt oder gelöscht). Und dann machen Sie ein großes Commit, das alle im neuen Repo vorgenommenen Änderungen als ein einziges Commit im alten Repo darstellt. Ist es möglich, die Geschichten zusammenzuführen? Vielleicht, wenn ich einen Zweig verwendet und dann die Objekte gelöscht habe, die ich nicht brauchte. (Ich weiß nicht genug über Git-Interna, um so herumzuspielen).

— Darrel Lee
quelle

1

Sie können stattdessen einfach Dropbox für diesen Anwendungsfall verwenden. Ich habe es viele Jahre lang getan.

— Jonny

0

Die oben beschriebenen Methoden haben in meinem Fall nichts funktioniert (wo ich den Git-Prozess versehentlich während des Git-Pushs abgebrochen habe), also musste ich das Repo endlich löschen und erneut klonen und jetzt hat der .git-Ordner die normale Größe.

— JerryGoyal
quelle

Ich musste dieselbe Lösung verwenden, da meine Festplatte voll war (.git-Ordner> 90 GB), sodass ich nicht einmal ein Repack oder git gc ausführen konnte!

— Fl4v