English ▾ Themen ▾ Neueste Version ▾ git-gc zuletzt aktualisiert in 2.52.0

NAME

git-gc - Bereinigt unnötige Dateien und optimiert das lokale Repository

SYNOPSIS

git gc [--aggressive] [--auto] [--[no-]detach] [--quiet] [--prune=<date> | --no-prune] [--force] [--keep-largest-pack]

BESCHREIBUNG

Führt eine Reihe von Wartungsaufgaben im aktuellen Repository durch, wie z. B. das Komprimieren von Dateirevisionen (zur Reduzierung des Speicherplatzes und zur Erhöhung der Leistung), das Entfernen von unerreichbaren Objekten, die möglicherweise durch frühere Aufrufe von git add erstellt wurden, das Packen von Referenzen, das Beschneiden von Reflogs, Rerere-Metadaten oder veralteten Arbeitsbäumen. Kann auch ergänzende Indizes wie den Commit-Graphen aktualisieren.

Wenn gängige Porcelain-Operationen, die Objekte erstellen, ausgeführt werden, prüfen diese, ob das Repository seit der letzten Wartung erheblich gewachsen ist. Wenn ja, wird git gc automatisch ausgeführt. Lesen Sie gc.auto unten, um dieses Verhalten zu deaktivieren.

Das manuelle Ausführen von git gc sollte nur dann erforderlich sein, wenn Objekte zu einem Repository hinzugefügt werden, ohne regelmäßig solche Porcelain-Befehle auszuführen, zur einmaligen Optimierung des Repositorys oder z. B. zur Bereinigung eines suboptimalen Massenimports. Weitere Details zum Importfall finden Sie im Abschnitt "PACKFILE OPTIMIZATION" in git-fast-import[1].

OPTIONEN

--aggressive

Normalerweise läuft git gc sehr schnell und bietet eine gute Auslastung des Speicherplatzes und Leistung. Diese Option bewirkt, dass git gc das Repository aggressiver optimiert, allerdings auf Kosten einer deutlich längeren Laufzeit. Die Auswirkungen dieser Optimierung sind größtenteils persistent. Details finden Sie im Abschnitt "AGGRESSIVE" unten.

--auto

Mit dieser Option prüft git gc, ob Wartungsarbeiten erforderlich sind; wenn nicht, wird die Ausführung ohne jegliche Arbeit beendet.

Sehen Sie die Option gc.auto im Abschnitt "CONFIGURATION" unten, um zu erfahren, wie diese Heuristik funktioniert.

Sobald Wartungsarbeiten durch Überschreiten der Grenzwerte von Konfigurationsoptionen wie gc.auto und gc.autoPackLimit ausgelöst werden, werden auch alle anderen Wartungsarbeiten (z. B. Rerere, Arbeitsbäume, Reflog usw.) durchgeführt.

--detach
--no-detach

Führen Sie im Hintergrund aus, wenn das System dies unterstützt. Diese Option überschreibt die gc.autoDetach Konfiguration.

--cruft
--no-cruft

Beim Ablauf unerreichbarer Objekte werden diese separat in ein "cruft pack" gepackt, anstatt sie als lose Objekte zu speichern. --cruft ist standardmäßig aktiviert.

--max-cruft-size=<n>

Beim Packen unerreichbarer Objekte in ein "cruft pack" wird die Größe neuer "cruft packs" auf maximal <n> Bytes begrenzt. Überschreibt jeden Wert, der über die Konfiguration gc.maxCruftSize angegeben wurde. Weitere Informationen finden Sie in der Option --max-cruft-size von git-repack[1].

--expire-to=<dir>

Beim Packen unerreichbarer Objekte in ein "cruft pack" wird ein "cruft pack" mit den bereinigten Objekten (falls vorhanden) in das Verzeichnis <dir> geschrieben. Diese Option hat nur eine Auswirkung, wenn sie zusammen mit --cruft verwendet wird. Weitere Informationen finden Sie in der Option --expire-to von git-repack[1].

--prune=<date>

Bereinigt lose Objekte, die älter als das angegebene Datum sind (Standard ist vor 2 Wochen, überschreibbar durch die Konfigurationsvariable gc.pruneExpire). --prune=now bereinigt lose Objekte unabhängig von ihrem Alter und erhöht das Risiko von Beschädigungen, wenn ein anderer Prozess gleichzeitig in das Repository schreibt; siehe "NOTES" unten. --prune ist standardmäßig aktiviert.

--no-prune

Keine losen Objekte bereinigen.

--quiet

Unterdrückt alle Fortschrittsanzeigen.

--force

Erzwingt die Ausführung von git gc, auch wenn möglicherweise eine andere git gc Instanz für dieses Repository ausgeführt wird.

--keep-largest-pack

Alle Packs außer dem größten Nicht-Cruft-Pack, allen mit einer .keep-Datei markierten Packs und allen Cruft-Packs werden zu einem einzigen Pack zusammengefasst. Wenn diese Option verwendet wird, wird gc.bigPackThreshold ignoriert.

AGGRESSIVE

Wenn die Option --aggressive übergeben wird, wird git-repack[1] mit dem Flag -f aufgerufen, das wiederum --no-reuse-delta an git-pack-objects[1] weitergibt. Dies verwirft alle vorhandenen Deltas und berechnet sie neu, auf Kosten einer deutlich längeren Umpackzeit.

Die Auswirkungen davon sind größtenteils persistent, z. B. wenn Packs und lose Objekte in ein anderes Pack zusammengeführt werden, können die vorhandenen Deltas in diesem Pack wiederverwendet werden, aber es gibt auch verschiedene Fälle, in denen wir möglicherweise ein suboptimale Delta aus einem neueren Pack stattdessen auswählen.

Darüber hinaus werden durch die Angabe von --aggressive die Optionen --depth und --window, die an git-repack[1] übergeben werden, angepasst. Sehen Sie sich die Einstellungen gc.aggressiveDepth und gc.aggressiveWindow unten an. Durch die Verwendung einer größeren Fenstergröße ist es wahrscheinlicher, dass wir optimalere Deltas finden.

Es lohnt sich wahrscheinlich nicht, diese Option für ein bestimmtes Repository zu verwenden, ohne darauf zugeschnittene Leistungsbenchmarks durchzuführen. Es dauert viel länger, und die daraus resultierende Platz-/Delta-Optimierung ist möglicherweise nicht lohnenswert. Wenn Sie diese Option gar nicht verwenden, ist dies für die meisten Benutzer und ihre Repositories der richtige Kompromiss.

KONFIGURATION

Alles unterhalb dieser Zeile in diesem Abschnitt wird selektiv aus der git-config[1]-Dokumentation übernommen. Der Inhalt ist derselbe wie dort zu finden.

gc.aggressiveDepth

Der Tiefenparameter, der im Delta-Kompressionsalgorithmus verwendet wird, der von git gc --aggressive verwendet wird. Dieser ist standardmäßig auf 50 eingestellt, was dem Standardwert für die Option --depth entspricht, wenn --aggressive nicht verwendet wird.

Weitere Einzelheiten finden Sie in der Dokumentation zur Option --depth in git-repack[1].

gc.aggressiveWindow

Der Fenstergrößenparameter, der im Delta-Kompressionsalgorithmus verwendet wird, der von git gc --aggressive verwendet wird. Dieser ist standardmäßig auf 250 eingestellt, was eine wesentlich aggressivere Fenstergröße ist als der Standardwert --window von 10.

Weitere Einzelheiten finden Sie in der Dokumentation zur Option --window in git-repack[1].

gc.auto

Wenn sich ungefähr mehr als diese Anzahl loser Objekte im Repository befindet, packt git gc --auto diese. Einige Porcelain-Befehle verwenden diesen Befehl, um gelegentlich eine leichtgewichtige Garbage Collection durchzuführen. Der Standardwert ist 6700.

Wenn Sie diesen Wert auf 0 setzen, werden nicht nur die automatische Packung basierend auf der Anzahl loser Objekte deaktiviert, sondern auch alle anderen Heuristiken, die git gc --auto sonst verwenden würde, um zu entscheiden, ob Arbeit zu tun ist, wie z. B. gc.autoPackLimit.

gc.autoPackLimit

Wenn mehr als diese Anzahl von Packs, die nicht mit einer *.keep-Datei gekennzeichnet sind, im Repository vorhanden ist, fasst git gc --auto diese zu einem größeren Pack zusammen. Der Standardwert ist 50. Das Setzen auf 0 deaktiviert dies. Das Setzen von gc.auto auf 0 deaktiviert dies ebenfalls.

Siehe die Konfigurationsvariable gc.bigPackThreshold unten. Wenn diese verwendet wird, beeinflusst sie, wie das automatische Pack-Limit funktioniert.

gc.autoDetach

Bewirkt, dass git gc --auto sofort zurückkehrt und im Hintergrund läuft, wenn das System dies unterstützt. Standard ist true. Diese Konfigurationsvariable dient als Fallback, falls maintenance.autoDetach nicht gesetzt ist.

gc.bigPackThreshold

Wenn ungleich Null, werden alle Nicht-Cruft-Packs, die größer als dieser Grenzwert sind, beim Ausführen von git gc beibehalten. Dies ähnelt stark --keep-largest-pack, außer dass alle Nicht-Cruft-Packs, die den Schwellenwert erfüllen, beibehalten werden, nicht nur das größte Pack. Standard ist Null. Übliche Einheiten-Suffixe wie k, m oder g werden unterstützt.

Beachten Sie, dass, wenn die Anzahl der beibehaltenen Packs größer ist als gc.autoPackLimit, diese Konfigurationsvariable ignoriert wird und alle Packs außer dem Basis-Pack neu verpackt werden. Danach sollte die Anzahl der Packs unter gc.autoPackLimit liegen und gc.bigPackThreshold sollte wieder respektiert werden.

Wenn die für git repack geschätzte Speichermenge nicht verfügbar ist und gc.bigPackThreshold nicht gesetzt ist, wird auch das größte Pack ausgeschlossen (dies entspricht dem Ausführen von git gc mit --keep-largest-pack).

gc.writeCommitGraph

Wenn true, dann wird gc die Commit-Graph-Datei neu schreiben, wenn git-gc[1] ausgeführt wird. Bei Verwendung von git gc --auto wird der Commit-Graph aktualisiert, wenn Wartungsarbeiten erforderlich sind. Standard ist true. Details finden Sie in git-commit-graph[1].

gc.logExpiry

Wenn die Datei gc.log existiert, dann gibt git gc --auto ihren Inhalt aus und beendet sich mit dem Status null, anstatt ausgeführt zu werden, es sei denn, diese Datei ist älter als gc.logExpiry. Standard ist "1.day". Weitere Möglichkeiten zur Angabe des Werts finden Sie bei gc.pruneExpire.

gc.packRefs

Das Ausführen von git pack-refs in einem Repository macht es für Git-Versionen vor 1.5.1.2 über dumme Transports wie HTTP unklonbar. Diese Variable bestimmt, ob git gc git pack-refs ausführt. Dies kann auf notbare gesetzt werden, um es in allen Nicht-Bare-Repos zu aktivieren, oder es kann auf einen booleschen Wert gesetzt werden. Der Standardwert ist true.

gc.cruftPacks

Speichert unerreichbare Objekte in einem "cruft pack" (siehe git-repack[1]) anstatt als lose Objekte. Der Standardwert ist true.

gc.maxCruftSize

Begrenzt die Größe neuer "cruft packs" beim Neuverpacken. Wenn dies zusätzlich zu --max-cruft-size angegeben wird, hat die Befehlszeilenoption Vorrang. Siehe die Option --max-cruft-size von git-repack[1].

gc.pruneExpire

Wenn git gc ausgeführt wird, ruft es prune --expire 2.weeks.ago auf (und repack --cruft --cruft-expiration 2.weeks.ago, wenn Cruft-Packs über gc.cruftPacks oder --cruft verwendet werden). Überschreiben Sie die Wartezeit mit dieser Konfigurationsvariable. Der Wert "now" kann verwendet werden, um diese Wartezeit zu deaktivieren und unerreichbare Objekte sofort zu bereinigen, oder "never" kann verwendet werden, um die Bereinigung zu unterdrücken. Dieses Feature hilft, Beschädigungen zu verhindern, wenn git gc gleichzeitig mit einem anderen Prozess ausgeführt wird, der in das Repository schreibt; siehe den Abschnitt "NOTES" von git-gc[1].

gc.worktreePruneExpire

Wenn git gc ausgeführt wird, ruft es git worktree prune --expire 3.months.ago auf. Diese Konfigurationsvariable kann verwendet werden, um eine andere Wartezeit festzulegen. Der Wert "now" kann verwendet werden, um die Wartezeit zu deaktivieren und $GIT_DIR/worktrees sofort zu bereinigen, oder "never" kann verwendet werden, um die Bereinigung zu unterdrücken.

gc.reflogExpire
gc.<pattern>.reflogExpire

git reflog expire entfernt Reflog-Einträge, die älter als diese Zeit sind; Standard sind 90 Tage. Der Wert "now" löscht alle Einträge sofort, und "never" unterdrückt das Löschen vollständig. Mit "<pattern>" (z. B. "refs/stash") in der Mitte gilt die Einstellung nur für die Referenzen, die dem Muster entsprechen.

gc.reflogExpireUnreachable
gc.<pattern>.reflogExpireUnreachable

git reflog expire entfernt Reflog-Einträge, die älter als diese Zeit sind und nicht vom aktuellen Tip erreichbar sind; Standard sind 30 Tage. Der Wert "now" löscht alle Einträge sofort, und "never" unterdrückt das Löschen vollständig. Mit "<pattern>" (z. B. "refs/stash") in der Mitte gilt die Einstellung nur für die Referenzen, die dem Muster entsprechen.

Diese Arten von Einträgen entstehen im Allgemeinen durch die Verwendung von git commit --amend oder git rebase und sind die Commits vor dem Amend oder Rebase. Da diese Änderungen nicht Teil des aktuellen Projekts sind, möchten die meisten Benutzer sie früher löschen, weshalb der Standard aggressiver ist als gc.reflogExpire.

gc.recentObjectsHook

Wenn entschieden wird, ob ein Objekt entfernt werden soll (entweder beim Erzeugen eines Cruft-Packs oder beim Speichern unerreichbarer Objekte als lose), wird die angegebene(n) Shell-Befehl(e) ausgeführt. Deren Ausgabe wird als Objekt-IDs interpretiert, die Git als "aktuell" betrachtet, unabhängig von ihrem Alter. Indem ihre mtimes als "jetzt" behandelt werden, werden alle in der Ausgabe genannten Objekte (und ihre Nachfolger) unabhängig von ihrem tatsächlichen Alter beibehalten.

Die Ausgabe muss genau eine Hex-Objekt-ID pro Zeile enthalten und sonst nichts. Objekte, die im Repository nicht gefunden werden können, werden ignoriert. Mehrere Hooks werden unterstützt, aber alle müssen erfolgreich beendet werden, andernfalls wird die Operation (entweder das Erzeugen eines Cruft-Packs oder das Entpacken unerreichbarer Objekte) abgebrochen.

gc.repackFilter

Beim Neuverpacken wird der angegebene Filter verwendet, um bestimmte Objekte in ein separates Packfile zu verschieben. Siehe die Option --filter=<filter-spec> von git-repack[1].

gc.repackFilterTo

Beim Neuverpacken und Verwenden eines Filters, siehe gc.repackFilter, wird der angegebene Speicherort verwendet, um das Packfile mit den gefilterten Objekten zu erstellen. WARNUNG: Der angegebene Speicherort sollte zugänglich sein, z. B. über den Git-Alternates-Mechanismus, andernfalls kann das Repo von Git als beschädigt betrachtet werden, da Git möglicherweise nicht auf die Objekte in diesem Packfile zugreifen kann. Siehe die Option --filter-to=<dir> von git-repack[1] und den Abschnitt objects/info/alternates von gitrepository-layout[5].

gc.rerereResolved

Aufzeichnungen von früher aufgelösten Konfliktmerges werden für diese Anzahl von Tagen aufbewahrt, wenn git rerere gc ausgeführt wird. Sie können auch menschenlesbare Angaben wie "1.month.ago" usw. verwenden. Der Standardwert ist 60 Tage. Siehe git-rerere[1].

gc.rerereUnresolved

Aufzeichnungen von unaufgelösten Konfliktmerges werden für diese Anzahl von Tagen aufbewahrt, wenn git rerere gc ausgeführt wird. Sie können auch menschenlesbare Angaben wie "1.month.ago" usw. verwenden. Der Standardwert ist 15 Tage. Siehe git-rerere[1].

ANMERKUNGEN

git gc versucht sehr stark, Objekte nicht zu löschen, die irgendwo in Ihrem Repository referenziert werden. Insbesondere werden nicht nur Objekte beibehalten, auf die Ihre aktuelle Menge an Branches und Tags verweist, sondern auch Objekte, auf die der Index, Remote-Tracking-Branches, Reflogs (die auf Commits in später geänderten oder zurückgespulten Branches verweisen können) und alles andere im Namespace refs/* verweist. Beachten Sie, dass eine Notiz (der Art, die von git notes erstellt wird) an ein Objekt angehängt ist, nicht dazu beiträgt, das Objekt am Leben zu erhalten. Wenn Sie erwarten, dass einige Objekte gelöscht werden und dies nicht geschieht, überprüfen Sie alle diese Orte und entscheiden Sie, ob es in Ihrem Fall sinnvoll ist, diese Referenzen zu entfernen.

Andererseits besteht beim gleichzeitigen Ausführen von git gc mit einem anderen Prozess das Risiko, ein Objekt zu löschen, das vom anderen Prozess verwendet wird, zu dem dieser aber noch keine Referenz erstellt hat. Dies kann dazu führen, dass der andere Prozess fehlschlägt, oder das Repository beschädigen, wenn der andere Prozess später eine Referenz zum gelöschten Objekt hinzufügt. Git verfügt über zwei Funktionen, die dieses Problem erheblich mildern:

  1. Jedes Objekt mit einer Änderungszeit, die neuer ist als das --prune-Datum, wird beibehalten, zusammen mit allem, was von ihm erreichbar ist.

  2. Die meisten Operationen, die ein Objekt zur Datenbank hinzufügen, aktualisieren die Änderungszeit des Objekts, wenn es bereits vorhanden ist, sodass #1 gilt.

Diese Funktionen reichen jedoch nicht aus, um eine vollständige Lösung zu bieten, sodass Benutzer, die Befehle gleichzeitig ausführen, mit einem gewissen Risiko von Beschädigungen leben müssen (das in der Praxis gering zu sein scheint).

HOOKS

Der Befehl git gc --auto führt den Hook pre-auto-gc aus. Weitere Informationen finden Sie in githooks[5].

SIEHE AUCH

git-prune[1] git-reflog[1] git-repack[1] git-rerere[1]

GIT

Teil der git[1] Suite