Übersicht
git for-each-ref [--format=<fmt>] [--sort=<key>] [<pattern>...]
Beschreibung
Der git for-each-ref-Befehl iteriert über jede Ref (Branches, Tags, Remotes, Notes, Stash) und wendet ein anpassbares Format an. Er ist weit mächtiger als das Parsen der Ausgaben von git branch oder git tag: Sie können nach Version, nach Datum oder nach beliebigem Feld sortieren und stabile maschinenlesbare Ausgabe erzeugen.
Im täglichen Einsatz integriert sich git for-each-ref 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 for-each-ref --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 for-each-ref 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 for-each-ref hilft, alle drei zu vermeiden.
Häufige Optionen
| Option | Beschreibung |
|---|---|
--format=<fmt> | Format-String mit Feld-Platzhaltern. |
--sort=<key> | Sortiert nach Feld (Präfix - für absteigend). |
--count=<n> | Begrenzt die Anzahl der Einträge. |
--contains <commit> | Refs, die den gegebenen Commit enthalten. |
--merged <commit> | Refs, die in den gegebenen Commit gemerged sind. |
--points-at <commit> | Refs, die direkt auf einen Commit zeigen. |
Beispiele
git for-each-ref --format='%(refname:short) %(objectname:short)' refs/heads/
# Lokale Branch-Namen mit abgekürzten SHAs
git for-each-ref --sort=-committerdate --count=10 \
--format='%(committerdate:short) %(refname:short)' refs/heads/
# Top 10 zuletzt aktualisierte Branches
git for-each-ref --sort=-v:refname --format='%(refname:short)' refs/tags/ | head -5
# Fünf höchste Semver-Tags
Häufige Fehler
Den abschließenden / bei refs/heads/-Mustern zu vergessen kann unbeabsichtigte Refs matchen. Format-Strings können knifflig sein — quoten Sie Feldnamen mit Klammern. --sort=v:refname funktioniert nur auf Tags, die wie Versionen aussehen.
Verwandte Befehle
git branch, git tag, git ls-remote, git rev-parse