Wie oft sollten Sie git-gc verwenden?

Wie oft sollten Sie git-gc verwenden?

Die Handbuchseite sagt einfach:

Benutzer werden aufgefordert, diese Aufgabe regelmäßig in jedem Repository auszuführen, um eine gute Speicherplatzauslastung und eine gute Betriebsleistung zu gewährleisten.

Gibt es einige Befehle, um einige Objektzählungen zu erhalten, um herauszufinden, ob es Zeit für gc ist?

Dies hängt hauptsächlich davon ab, wie oft das Repository verwendet wird. Wenn ein Benutzer einmal am Tag eincheckt und einmal pro Woche eine Verzweigung / Zusammenführung / usw. ausgeführt wird, müssen Sie diese wahrscheinlich nicht mehr als einmal im Jahr ausführen.

Wenn mehrere Dutzend Entwickler an mehreren Dutzend Projekten arbeiten, die jeweils 2-3 Mal am Tag einchecken, möchten Sie es möglicherweise jede Nacht ausführen.

Es wird jedoch nicht schaden, es häufiger als nötig auszuführen.

Ich würde es jetzt ausführen und dann in einer Woche die Festplattenauslastung messen, erneut ausführen und die Festplattenauslastung erneut messen. Wenn die Größe um 5% abnimmt, führen Sie sie einmal pro Woche aus. Wenn es mehr abfällt, führen Sie es häufiger aus. Wenn es weniger abfällt, führen Sie es weniger häufig aus.

Beachten Sie, dass der Nachteil beim Sammeln von Müll in Ihrem Repository darin besteht, dass der Müll gesammelt wird. Wie wir alle als Computerbenutzer wissen, könnten sich Dateien, die wir derzeit als Müll betrachten, in drei Tagen als sehr wertvoll herausstellen. Die Tatsache, dass Git den größten Teil seiner Trümmer in der Nähe hält, hat meinen Speck mehrmals gerettet - durch Durchsuchen aller baumelnden Commits habe ich viel Arbeit zurückgewonnen, die ich versehentlich eingemacht hatte.

Sei also nicht zu ein ordentlicher Freak in deinen privaten Klonen. Es besteht wenig Bedarf dafür.

OTOH, der Wert der Datenwiederherstellbarkeit ist für Repos fraglich, die hauptsächlich als Fernbedienungen verwendet werden, z. der Ort, zu dem alle Entwickler schieben und / oder ziehen. Dort kann es sinnvoll sein, häufig einen GC-Lauf und ein Umpacken zu starten.

Neuere Versionen von git führen gc bei Bedarf automatisch aus, sodass Sie nichts tun müssen. Siehe den Abschnitt Optionen von man git-gc (1) : "Einige git-Befehle führen git gc --auto aus, nachdem Operationen ausgeführt wurden, die viele lose Objekte erstellen könnten."

Wenn Sie Git-Gui verwenden , erfahren Sie, wann Sie sich Sorgen machen sollten:

This repository currently has approximately 1500 loose objects.

Der folgende Befehl bringt eine ähnliche Nummer:

$ git count-objects

Abgesehen davon , dass Git-GUI von seiner Quelle aus die Mathematik selbst erledigt, tatsächlich etwas im .git/objectsOrdner zählt und wahrscheinlich eine Annäherung bringt (ich weiß nicht, tclob ich das richtig lesen soll!).

In jedem Fall scheint es die Warnung zu geben, die auf einer beliebigen Zahl von etwa 300 losen Objekten basiert .

Lassen Sie es in einem Cron-Job fallen, der jede Nacht (nachmittags?) Läuft, wenn Sie schlafen.

Ich benutze git gc, nachdem ich eine große Kasse gemacht habe, und habe viele neue Objekte. es kann platz sparen. Wenn Sie beispielsweise ein großes SVN-Projekt mit git-svn auschecken und ein git gc ausführen, sparen Sie normalerweise viel Platz

Mit der neuen Einstellung (Git 2.0 Q2 2014) können Sie dies ohne Unterbrechung tun gc.autodetach.

Siehe Commit 4c4ac4d und Commit 9f673f9 ( Nguyễn Thái Ngọc Duy, auch bekannt als pclouds ):

gc --autobraucht Zeit und kann den Benutzer vorübergehend blockieren (aber nicht weniger ärgerlich).
Lassen Sie es auf Systemen, die es unterstützen, im Hintergrund laufen.
Das einzige, was beim Laufen im Hintergrund verloren geht, sind Ausdrucke. Ist gc outputaber nicht wirklich interessant.
Sie können es durch Ändern im Vordergrund halten gc.autodetach.

Seit dieser Version 2.0 gab es jedoch einen Fehler: Git 2.7 (Q4 2015) stellt sicher, dass die Fehlermeldung nicht verloren geht .
Siehe Commit 329e6e8 (19. September 2015) von Nguyễn Thái Ngọc Duy ( pclouds) .
^{(Zusammengeführt von Junio ​​C Hamano - gitster- in Commit 076c827 , 15. Oktober 2015)}

gc: Speichern Sie das Protokoll von daemonized gc --autound drucken Sie es beim nächsten Mal aus

Während Commit 9f673f9 ( gc: Konfigurationsoption für die Ausführung --autoim Hintergrund - 08.02.2014) dazu beiträgt, einige Beschwerden über das gc --auto"Hoggen des Terminals" zu reduzieren , führt dies zu weiteren Problemen.

Das Neueste in diesem Satz ist als Ergebnis der Dämonisierung stderrgeschlossen und alle Warnungen gehen verloren. Diese Warnung am Ende von cmd_gc()ist besonders wichtig, da sie dem Benutzer sagt, wie er vermeiden soll gc --auto, dass wiederholt wiederholt wird.
Da stderr geschlossen ist, weiß der Benutzer es nicht, natürlich beschweren sie sich über gc --autodie Verschwendung von CPU.

Daemonized gcspeichert jetzt stderrin $GIT_DIR/gc.log.
Das Folgende gc --autowird erst ausgeführt und gc.logausgedruckt, wenn der Benutzer es entferntgc.log .

Dieses Zitat stammt aus; Versionskontrolle mit Git

Git führt die Speicherbereinigung automatisch aus :

• Wenn sich zu viele lose Objekte im Repository befinden

• Wenn ein Push in ein Remote-Repository erfolgt

• Nach einigen Befehlen, die möglicherweise viele lose Objekte einführen

• Wenn einige Befehle wie git reflog explizit ablaufen, fordern Sie sie explizit an

Und schließlich erfolgt die Speicherbereinigung, wenn Sie sie explizit mit dem Befehl git gc anfordern. Aber wann sollte das sein? Es gibt keine solide Antwort auf diese Frage, aber es gibt einige gute Ratschläge und bewährte Verfahren.

Sie sollten in einigen Situationen in Betracht ziehen, git gc manuell auszuführen:

• Wenn Sie gerade einen Git-Filter-Zweig abgeschlossen haben. Denken Sie daran, dass der Filterzweig viele Commits neu schreibt, neue einführt und die alten auf einem Verweis belässt, der entfernt werden sollte, wenn Sie mit den Ergebnissen zufrieden sind. Alle toten Objekte (auf die nicht mehr verwiesen wird, da Sie gerade den einen Verweis entfernt haben, der auf sie verweist) sollten über die Speicherbereinigung entfernt werden.

• Nach einigen Befehlen, die möglicherweise viele lose Objekte einführen. Dies kann beispielsweise ein großer Rebase-Aufwand sein.

Und auf der anderen Seite, wann sollten Sie sich vor der Müllabfuhr in Acht nehmen?

• Wenn es verwaiste Refs gibt, die Sie möglicherweise wiederherstellen möchten

• Im Kontext von git rerere müssen Sie die Auflösungen nicht für immer speichern

• Wenn nur Tags und Zweige ausreichen, um Git zu veranlassen, ein Commit dauerhaft beizubehalten

• Im Zusammenhang mit FETCH_HEAD-Abrufen (URL-direkte Abfragen über Git-Fetch), da diese sofort einer Speicherbereinigung unterliegen

Ich verwende es, wenn ich ein großes Commit mache, vor allem, wenn ich mehr Dateien aus dem Repository entferne. Danach sind die Commits schneller

Sie müssen nicht git gcsehr oft verwenden, da git gc(Garbage Collection) automatisch für mehrere häufig verwendete Befehle ausgeführt wird:

git pull
git merge
git rebase
git commit

Quelle: git gc Best Practices und FAQs