Git prune

In der git log-Ausgabe werden die zwei Commits und die entsprechenden Commit-Meldungen über die an hello.txt vorgenommenen Änderungen angezeigt. Als Nächstes machen wir einen der Commits unerreichbar. Hierfür verwenden wir den Befehl git reset. Wir setzen den Status des Repositorys auf den ersten Commit ("added hello.txt") zurück.

Wenn wir jetzt mit git log den Status des Repositorys untersuchen, sehen wir nur einen Commit.

Das Demo-Repository befindet sich jetzt in einem Zustand, der einen losgelösten Commit enthält. Der zweite Commit, den wir mit der Nachricht "added another line to hello.txt" erstellt haben, wird nicht mehr in der git log-Ausgabe angezeigt und ist jetzt losgelöst. Es mag den Anschein haben, als hätten wir den Commit verloren oder gelöscht, aber Git achtet sehr darauf, den Verlauf nicht zu löschen. Wir können bestätigen, dass er noch verfügbar, aber losgelöst ist, indem wir git checkout verwenden, um ihn direkt aufzurufen:

Wenn wir uns den losgelösten Commit ansehen, zeigt Git eine detaillierte Meldung an, dass wir uns in einem losgelösten Zustand befinden. Im Protokoll sehen wir, dass der Commit "added another line to hello.txt" jetzt wieder in der Protokollausgabe steht. Nachdem wir jetzt wissen, dass sich das Repository mit einem losgelösten Commit in einem guten Simulationszustand befindet, können wir die Verwendung von git prune üben. Kehren wir jedoch zunächst mit git checkout zurück zum main-Branch.

Bei der Rückkehr zum Main-Branch mit git checkout teilt uns Git wieder mit, dass wir einen losgelösten Commit verlassen. Jetzt ist es an der Zeit, den losgelösten Commit mit "prune" zu löschen. Als Nächstes führen wir git prune aus, aber wir müssen unbedingt einige Optionen hinzufügen. Mit --dry-runn und --verbose wird in der Ausgabe angegeben, was mit "prune" gelöscht werden soll, ohne dies tatsächlich zu tun.

Dieser Befehl wird höchstwahrscheinlich eine leere Ausgabe zurückgeben. Eine leere Ausgabe bedeutet, dass der Prune-Befehl nichts wirklich löscht. Warum geschieht dies? Nun, der Commit ist höchstwahrscheinlich nicht vollständig losgelöst. Irgendwo bewahrt Git immer noch einen Verweis darauf. Dies ist ein Paradebeispiel dafür, warum git prune nicht eigenständig außerhalb von git gc verwendet werden darf. Dies ist auch ein gutes Beispiel dafür, wie schwierig es ist, Daten in Git vollständig zu verlieren.

Höchstwahrscheinlich speichert Git einen Verweis auf unseren losgelösten Commit im Reflog. Dies können wir untersuchen, indem wir git reflog ausführen. Hiermit wird eine Ausgabe mit der Reihenfolge der Aktionen zurückgegeben, die wir durchgeführt haben, um hierher zu gelangen. Weitere Informationen zu git reflog findest du auf der git reflog-Seite. Zusätzlich zum Bewahren des Verlaufs im Reflog verfügt Git über interne Ablaufdaten, an denen losgelöste Commits mit "prune" gelöscht werden. Nochmals: Dies sind alles Implementierungsdetails, die git gc handhabt und weswegen git prune nicht eigenständig verwendet werden sollte.

Um unsere Demo zur git prune-Simulation abzuschließen, müssen wir den Reflog löschen.

Der obige Befehl erzwingt das Ablaufen aller Einträge im Reflog, die älter als jetzt sind. Dies ist ein schonungsloser und gefährlicher Befehl, den du als Gelegenheitsbenutzer von Git niemals verwenden solltest. Wir führen diesen Befehl aus, um eine erfolgreiche Ausführung von git prune zu demonstrieren. Da der Reflog vollständig gelöscht ist, können wir jetzt git prune ausführen.

Dieser Befehl sollte eine Liste von Git SHA-Objektreferenzen ausgeben, die wie oben abgebildet aussehen.

git prune hat eine kurze Liste von Optionen, die wir im Übersichtsbereich behandelt haben.

Der Prune-Befehl wird nicht ausgeführt. Es wird nur angezeigt, was bei der Ausführung des Befehls geschehen würde.

Die Ausgabe zeigt alle Objekte und Aktionen an, die vom Prune-Befehl ausgeführt wurden.

Die Ausgabe zeigt den Fortschritt des Prune-Befehls an.

Erzwingt das Ablaufen von Objekten, deren Fälligkeitsdatum erreicht wurde.

Durch die Angabe eines ＜head＞ werden alle Optionen aus dieser HEAD-Ref beibehalten.

git remote prune und git fetch --prune machen dasselbe: Sie löschen die Referenzen in Branches, die im Remote nicht existieren. Dies ist sehr wünschenswert, wenn du in einem Team-Workflow arbeitest, in dem Remote-Branches nach dem Merge mit main gelöscht werden. Der zweite Befehl, git fetch --prune, stellt eine Verbindung zum Remote her und ruft vor dem Pruning den neuesten Remote-Status ab. Im Wesentlichen ist dies eine Kombination von Befehlen:

Der generische Befehl git prune ist völlig anders. Wie im Übersichtsabschnitt erläutert, löscht Git Prune lokal losgelöste Commits.

git fetch --prune ist das beste Dienstprogramm zum Bereinigen veralteter Branches. Es stellt eine Verbindung zu einem gemeinsamen Remote-Repository her und ruft alle Remote-Branch-Refs ab. Anschließend werden Remote-Refs gelöscht, die nicht mehr im Remote-Repository verwendet werden.

Nein. git remote prune origin löscht nur die Referenzen auf Remote-Branches, die nicht mehr existieren. Git speichert sowohl lokale als auch Remote-Referenzen. Ein Repository verfügt über die Referenzsammlungen local/origin und remote/origin. git remote prune origin entfernt nur die Refs in remote/origin. Dadurch ist die lokale Arbeit in local/origin in Sicherheit.

Der Befehl git prune soll als untergeordneter Befehl für git gc aufgerufen werden. Es ist höchst unwahrscheinlich, dass du als Softwareentwickler git prune jemals im Alltag aufrufen musst. Um die Auswirkungen von git prune zu verstehen, sind weitere Befehle erforderlich. Einige in diesem Artikel verwendete Befehle waren git log, git reflog und git checkout.