Führt eine oder mehrere Wartungsaufgaben aus. Wenn ein oder mehrere --task-Optionen angegeben sind, werden diese Aufgaben in dieser Reihenfolge ausgeführt. Andernfalls werden die Aufgaben durch die Konfigurationsoptionen bestimmt, bei denen maintenance.<task>.enabled wahr ist. Standardmäßig ist nur maintenance.gc.enabled wahr.

Startet die Wartung des aktuellen Repositorys. Dies führt dieselben Konfigurationsaktualisierungen durch wie der Unterbefehl register, und aktualisiert dann den Hintergrundplaner, um git maintenance run --scheduled stündlich auszuführen.

Hält den Hintergrundwartungsplan an. Das aktuelle Repository wird nicht aus der Liste der gewarteten Repositories entfernt, falls die Hintergrundwartung später neu gestartet wird.

Initialisiert Git-Konfigurationswerte, damit jede geplante Wartung für dieses Repository ausgeführt wird. Dies fügt das Repository zur Konfigurationsvariable maintenance.repo in der globalen Konfiguration des aktuellen Benutzers oder in der durch die Option --config-file angegebenen Konfiguration hinzu und aktiviert einige empfohlene Konfigurationswerte für maintenance.<task>.schedule. Die aktivierten Aufgaben sind für die Ausführung im Hintergrund sicher, ohne Vordergrundprozesse zu stören.

Entfernt das aktuelle Repository aus der Hintergrundwartung. Dies entfernt nur das Repository aus der konfigurierten Liste. Es stoppt nicht die Ausführung der Hintergrundwartungsprozesse.

Der commit-graph-Job aktualisiert die commit-graph-Dateien inkrementell und verifiziert anschließend, dass die geschriebenen Daten korrekt sind. Das inkrementelle Schreiben ist sicher neben gleichzeitigen Git-Prozessen, da es .graph-Dateien, die in der vorherigen commit-graph-chain-Datei enthalten waren, nicht ablaufen lässt. Sie werden bei einem späteren Lauf aufgrund der Ablaufverzögerung gelöscht.

Die prefetch-Aufgabe aktualisiert das Objektverzeichnis mit den neuesten Objekten aus allen registrierten Remote-Repositories. Für jedes Remote-Repository wird ein git fetch-Befehl ausgeführt. Die konfigurierte Refspec wird modifiziert, um alle angeforderten Refs innerhalb von refs/prefetch/ zu platzieren. Tags werden ebenfalls nicht aktualisiert.

Bereinigt unnötige Dateien und optimiert das lokale Repository. "GC" steht für "Garbage Collection", aber diese Aufgabe führt viele kleinere Aufgaben aus. Diese Aufgabe kann bei großen Repositories kostspielig sein, da sie alle Git-Objekte in eine einzige Pack-Datei neu verpackt. Sie kann auch in einigen Situationen störend sein, da sie veraltete Daten löscht. Weitere Details zur Garbage Collection in Git finden Sie unter git-gc[1].

Der loose-objects-Job bereinigt lose Objekte und packt sie in Pack-Dateien. Um Race Conditions mit gleichzeitigen Git-Befehlen zu vermeiden, folgt er einem zweistufigen Prozess. Erstens löscht er alle losen Objekte, die bereits in einer Pack-Datei vorhanden sind; gleichzeitige Git-Prozesse werden stattdessen die Pack-Datei für die Objekt-Daten untersuchen. Zweitens erstellt er eine neue Pack-Datei (beginnend mit "loose-"), die eine Charge von losen Objekten enthält.

Der incremental-repack-Job verpackt das Objektverzeichnis neu, indem er die Funktion multi-pack-index verwendet. Um Race Conditions mit gleichzeitigen Git-Befehlen zu vermeiden, folgt er einem zweistufigen Prozess. Erstens ruft er git multi-pack-index expire auf, um Pack-Dateien zu löschen, die nicht von der multi-pack-index-Datei referenziert werden. Zweitens ruft er git multi-pack-index repack auf, um mehrere kleine Pack-Dateien auszuwählen und sie in eine größere neu zu verpacken. Anschließend aktualisiert er die multi-pack-index-Einträge, die auf die kleinen Pack-Dateien verweisen, sodass sie auf die neue Pack-Datei verweisen. Dies bereitet die kleinen Pack-Dateien für die Löschung bei der nächsten Ausführung von git multi-pack-index expire vor. Die Auswahl der kleinen Pack-Dateien erfolgt so, dass die erwartete Größe der großen Pack-Datei mindestens der Chargengröße entspricht; siehe die Option --batch-size für den Unterbefehl repack in git-multi-pack-index[1]. Die Standard-Chargengröße ist null, was ein Sonderfall ist, bei dem versucht wird, alle Pack-Dateien in eine einzige Pack-Datei zu verpacken.

Die pack-refs-Aufgabe sammelt die losen Referenzdateien und fasst sie in einer einzigen Datei zusammen. Dies beschleunigt Operationen, die viele Referenzen durchlaufen müssen. Weitere Informationen finden Sie unter git-pack-refs[1].

Die reflog-expire-Aufgabe löscht alle Einträge im Reflog, die älter als der Ablaufschwellenwert sind. Weitere Informationen finden Sie unter git-reflog[1].

Die rerere-gc-Aufgabe ruft eine Garbage Collection für veraltete Einträge im rerere-Cache auf. Weitere Informationen finden Sie unter git-rerere[1].

Die worktree-prune-Aufgabe löscht veraltete oder fehlerhafte Worktrees. Weitere Informationen finden Sie unter git-worktree[1].

In Kombination mit dem Unterbefehl run werden Wartungsaufgaben nur ausgeführt, wenn bestimmte Schwellenwerte erreicht sind. Beispielsweise wird die gc-Aufgabe ausgeführt, wenn die Anzahl der losen Objekte die in der gc.auto-Konfiguration gespeicherte Anzahl überschreitet, oder wenn die Anzahl der Pack-Dateien die gc.autoPackLimit-Konfigurationseinstellung überschreitet. Nicht kompatibel mit der Option --schedule.

In Kombination mit dem Unterbefehl run werden Wartungsaufgaben nur ausgeführt, wenn bestimmte zeitliche Bedingungen erfüllt sind, wie sie durch den Konfigurationswert maintenance.<task>.schedule für jede <task> festgelegt sind. Dieser Konfigurationswert gibt die Anzahl der Sekunden seit der letzten Ausführung der Aufgabe an, gemäß dem Konfigurationswert maintenance.<task>.lastRun. Die getesteten Aufgaben sind diejenigen, die durch die Option(en) --task=<task> bereitgestellt werden, oder diejenigen, bei denen maintenance.<task>.enabled auf wahr gesetzt ist.

Berichtet keinen Fortschritt oder andere Informationen über stderr.

Wenn diese Option ein- oder mehrmals angegeben wird, werden nur die angegebenen Aufgaben in der angegebenen Reihenfolge ausgeführt. Wenn keine --task=<task>-Argumente angegeben sind, werden nur die Aufgaben berücksichtigt, bei denen maintenance.<task>.enabled auf true konfiguriert ist. Die Liste der akzeptierten <task>-Werte finden Sie im Abschnitt AUFGABEN.

In Kombination mit dem Unterbefehl start wird der Scheduler für die stündliche, tägliche und wöchentliche Ausführung von git maintenance run angegeben. Mögliche Werte für <scheduler> sind auto, crontab (POSIX), systemd-timer (Linux), launchctl (macOS) und schtasks (Windows). Wenn auto angegeben ist, wird der entsprechende plattformspezifische Scheduler verwendet; unter Linux wird systemd-timer verwendet, wenn verfügbar, andernfalls crontab. Standard ist auto.

Diese boolesche Konfigurationsoption steuert, ob einige Befehle git maintenance run --auto ausführen, nachdem sie ihre normale Arbeit erledigt haben. Standardmäßig ist sie auf true gesetzt.

Viele Git-Befehle lösen nach dem Schreiben von Daten in das Repository eine automatische Wartung aus. Diese boolesche Konfigurationsoption steuert, ob diese automatische Wartung im Vordergrund stattfinden soll oder ob der Wartungsprozess sich abkoppeln und im Hintergrund weiterlaufen soll.

Diese String-Konfigurationsoption bietet eine Möglichkeit, eine von mehreren empfohlenen Strategien für die Repository-Wartung anzugeben. Dies beeinflusst, welche Aufgaben während git maintenance run ausgeführt werden, vorausgesetzt, es werden keine --task=<task>-Argumente angegeben. Diese Einstellung beeinflusst sowohl manuelle Wartung, Automatikwartung als auch geplante Wartung. Die ausgeführten Aufgaben können je nach Wartungstyp unterschiedlich sein.

Diese boolesche Konfigurationsoption steuert, ob die Wartungsaufgabe mit dem Namen <task> ausgeführt wird, wenn keine --task-Option an git maintenance run übergeben wird. Diese Konfigurationswerte werden ignoriert, wenn eine --task-Option vorhanden ist. Standardmäßig ist nur maintenance.gc.enabled auf true gesetzt.

Diese Konfigurationsoption steuert, ob die angegebene <task> während eines Befehls git maintenance run --schedule=<frequency> ausgeführt wird oder nicht. Der Wert muss einer der folgenden sein: "hourly", "daily" oder "weekly".

Diese Integer-Konfigurationsoption steuert, wie oft die commit-graph-Aufgabe im Rahmen von git maintenance run --auto ausgeführt werden soll. Wenn Null, wird die commit-graph-Aufgabe nicht mit der Option --auto ausgeführt. Ein negativer Wert erzwingt die einmalige Ausführung der Aufgabe. Andernfalls bedeutet ein positiver Wert, dass der Befehl ausgeführt werden soll, wenn die Anzahl der erreichbaren Commits, die sich nicht in der Commit-Graph-Datei befinden, mindestens dem Wert von maintenance.commit-graph.auto entspricht. Der Standardwert ist 100.

Diese Integer-Konfigurationsoption steuert, wie oft die loose-objects-Aufgabe im Rahmen von git maintenance run --auto ausgeführt werden soll. Wenn Null, wird die loose-objects-Aufgabe nicht mit der Option --auto ausgeführt. Ein negativer Wert erzwingt die einmalige Ausführung der Aufgabe. Andernfalls bedeutet ein positiver Wert, dass der Befehl ausgeführt werden soll, wenn die Anzahl der losen Objekte mindestens dem Wert von maintenance.loose-objects.auto entspricht. Der Standardwert ist 100.

Diese Integer-Konfigurationsoption steuert die maximale Anzahl loser Objekte, die während der loose-objects-Aufgabe in eine Pack-Datei geschrieben werden. Der Standardwert ist fünfzigtausend. Verwenden Sie den Wert 0, um kein Limit anzugeben.

Diese Integer-Konfigurationsoption steuert, wie oft die Aufgabe incremental-repack als Teil von git maintenance run --auto ausgeführt werden soll. Wenn der Wert Null ist, wird die Aufgabe incremental-repack nicht mit der Option --auto ausgeführt. Ein negativer Wert erzwingt die Ausführung der Aufgabe bei jedem Aufruf. Andernfalls bedeutet ein positiver Wert, dass der Befehl ausgeführt werden soll, wenn die Anzahl der Packdateien, die sich nicht im Multi-Pack-Index befinden, mindestens dem Wert von maintenance.incremental-repack.auto entspricht. Der Standardwert ist 10.

Diese Integer-Konfigurationsoption steuert, wie oft die Aufgabe geometric-repack als Teil von git maintenance run --auto ausgeführt werden soll. Wenn der Wert Null ist, wird die Aufgabe geometric-repack nicht mit der Option --auto ausgeführt. Ein negativer Wert erzwingt die Ausführung der Aufgabe bei jedem Aufruf. Andernfalls bedeutet ein positiver Wert, dass der Befehl entweder ausgeführt werden soll, wenn Packdateien zusammengeführt werden müssen, um die geometrische Progression beizubehalten, oder wenn mindestens so viele lose Objekte vorhanden sind, die in eine neue Packdatei geschrieben würden. Der Standardwert ist 100.

Diese Integer-Konfigurationsoption steuert den Faktor, der für die geometrische Folge verwendet wird. Weitere Details finden Sie in der Option --geometric= in git-repack[1]. Der Standardwert ist 2.

Diese Integer-Konfigurationsoption steuert, wie oft die Aufgabe reflog-expire als Teil von git maintenance run --auto ausgeführt werden soll. Wenn der Wert Null ist, wird die Aufgabe reflog-expire nicht mit der Option --auto ausgeführt. Ein negativer Wert erzwingt die Ausführung der Aufgabe bei jedem Aufruf. Andernfalls bedeutet ein positiver Wert, dass der Befehl ausgeführt werden soll, wenn die Anzahl der abgelaufenen Reflog-Einträge im "HEAD"-Reflog mindestens dem Wert von maintenance.loose-objects.auto entspricht. Der Standardwert ist 100.

Diese Integer-Konfigurationsoption steuert, wie oft die Aufgabe rerere-gc als Teil von git maintenance run --auto ausgeführt werden soll. Wenn der Wert Null ist, wird die Aufgabe rerere-gc nicht mit der Option --auto ausgeführt. Ein negativer Wert erzwingt die Ausführung der Aufgabe bei jedem Aufruf. Andernfalls bedeutet jeder positive Wert, dass der Befehl ausgeführt wird, wenn das Verzeichnis "rr-cache" existiert und mindestens einen Eintrag hat, unabhängig davon, ob dieser veraltet ist oder nicht. Diese Heuristik kann in Zukunft verfeinert werden. Der Standardwert ist 1.

Diese Integer-Konfigurationsoption steuert, wie oft die Aufgabe worktree-prune als Teil von git maintenance run --auto ausgeführt werden soll. Wenn der Wert Null ist, wird die Aufgabe worktree-prune nicht mit der Option --auto ausgeführt. Ein negativer Wert erzwingt die Ausführung der Aufgabe bei jedem Aufruf. Andernfalls bedeutet ein positiver Wert, dass der Befehl ausgeführt werden soll, wenn die Anzahl der bereinigbaren Arbeitsverzeichnisse den Wert überschreitet. Der Standardwert ist 1.