Übersicht

git ls-remote [--heads] [--tags] [<repository> [<refs>...]]

Beschreibung

Der git ls-remote-Befehl fragt einen Remote ab (ohne zu klonen oder zu fetchen) und gibt den SHA-1 jeder Ref neben dem Ref-Namen aus. Er ist unschätzbar für Skripting, CI-Pipelines und schnelle Inspektion — etwa um den neuesten Tag auf einem Remote zu finden oder zu prüfen, ob ein Branch existiert. Da er keine Objekte herunterlädt, ist er auch gegenüber sehr großen Repositories leichtgewichtig und schnell.

Sie können eine URL direkt übergeben, ohne zuerst einen Remote zu konfigurieren: git ls-remote https://github.com/user/repo.git. Das macht ihn ideal für einmalige Inspektionen oder Build-Skripte, die eine "neueste"-Version auflösen.

Im täglichen Einsatz integriert sich git ls-remote 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 ls-remote --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 ls-remote 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 ls-remote hilft, alle drei zu vermeiden.

Häufige Optionen

Option	Beschreibung
--heads / -h	Beschränkt die Ausgabe auf Branch-Refs.
--tags / -t	Beschränkt die Ausgabe auf Tag-Refs.
--refs	Filtert die dereferenzierte Peel von annotated Tags heraus.
--symref	Zeigt, worauf symbolische Refs (wie HEAD) zeigen.
--exit-code	Beendet sich mit Nicht-Null, wenn keine passenden Refs gefunden werden.
--sort=<key>	Sortiert Ergebnisse nach Version, refname usw.

Beispiele

git ls-remote --heads origin
    # Alle Branches auf origin mit ihren SHAs auflisten

    git ls-remote --tags --refs origin
    # Alle Tags auflisten (^{}-Dereferenzierungen überspringen)

    git ls-remote https://github.com/git/git.git HEAD
    # Anzeigen, worauf HEAD auf einem öffentlichen Repo zeigt

    git ls-remote --sort=-v:refname --tags origin 'v*' | head -1
    # Den höchsten Semver-Tag finden

Häufige Fehler

Die Ausgabe ohne --refs zu parsen, zeigt annotated Tags zweimal (einmal als Tag-Objekt, einmal als name^{} für den zugrunde liegenden Commit). Verwenden Sie --refs, um die gepeelten Zeilen zu unterdrücken. Authentifizierung kann gegen private Repos ohne Credential-Helper still scheitern — testen Sie zuerst interaktiv.

Verwandte Befehle

git remote, git fetch, git tag, git for-each-ref