Übersicht

git rev-list [<options>] <commit>...

Beschreibung

Der git rev-list-Befehl gibt die SHAs von Commits aus, die von einem oder mehreren Startpunkten erreichbar sind, optional unter Ausschluss anderer. Er ist das Arbeitspferd hinter git log, git bisect und vielen anderen Befehlen. Mit seinen vielen Filtern kann er beantworten "wie viele Commits zwischen A und B", "der SHA der Merge-Base", "alle Commits, die nicht auf main sind" usw.

Im täglichen Einsatz integriert sich git rev-list eng mit Shell-Aliasen, Editor-Plugins und Continuous Integration. Power-User fügen oft Aliase hinzu, die Flags kombinieren, die sie immer übergeben, oder wickeln den Befehl in Skripte, die Teamkonventionen durchsetzen. Die Ausgabeformatierung kann über Git-Config angepasst werden — Pretty-Formate, Farbschemata und Pager-Verhalten sind alle einstellbar. Wenn etwas schiefgeht, ist der erste Diagnoseschritt üblicherweise, den Befehl erneut mit GIT_TRACE=1 in der Umgebung auszuführen, was die zugrunde liegenden Plumbing-Aufrufe offenlegt. Für ungewöhnliche Situationen öffnet die --help-Ausgabe (git rev-list --help) die vollständige Manpage mit Details zu jeder Option, einschließlich solcher, die in alltäglichen Workflows selten verwendet werden, aber für Debugging oder Skripting im großen Maßstab essentiell sind.

Zu verstehen, wie git rev-list mit dem Rest von Gits Datenmodell interagiert — der Objektdatenbank, dem Index, Refs und dem Working Tree — zahlt sich aus. Jeder Befehl operiert auf einer Teilmenge dieser Stücke, und zu wissen, welche er berührt, hilft Ergebnisse vorherzusagen und sich von Fehlern zu erholen. Das Lesen der offiziellen Git-Dokumentation neben praktischer Übung in einem Wegwerf-Repository ist der schnellste Weg, die Nuancen zu verinnerlichen. Die meisten Produktionsprobleme mit Git rühren von einer von drei Ursachen: überraschendem Standardverhalten, partiellen Netzwerkoperationen oder dem Umschreiben bereits geteilter Historie. Ein funktionierendes mentales Modell der Nebenwirkungen von git rev-list hilft, alle drei zu vermeiden.

Häufige Optionen

Option	Beschreibung
--count	Gibt nur die Anzahl der Commits aus.
--max-count=<n>	Begrenzt die Anzahl aufzulistender Commits.
--reverse	Älteste zuerst ausgeben.
--no-merges	Schließt Merge-Commits aus.
--first-parent	Folgt nur dem ersten Elternteil jedes Merges.
--ancestry-path	Beschränkt auf Commits zwischen zwei Endpunkten.
--all	Bezieht jede Ref als Startpunkt ein.

Beispiele

git rev-list --count HEAD
    # Gesamtzahl der von HEAD aus erreichbaren Commits

    git rev-list main..feature
    # SHAs, die nur auf feature liegen

    git rev-list --no-merges --since="1 month ago" main
    # Nicht-Merge-Commits im letzten Monat

    git rev-list --max-parents=0 HEAD
    # Wurzel-Commits finden (keine Eltern)

Häufige Fehler

Vergessen, dass Bereiche mit zwei Punkten von der linken Seite aus erreichbare Commits ausschließen. --first-parent ändert die Bedeutung von "Vorfahrenschaft" erheblich. Auf riesigen Repos kann unbegrenztes rev-list langsam sein — paaren Sie mit --max-count oder Pfadfiltern.

Verwandte Befehle

git log, git rev-parse, git merge-base, git bisect