Übersicht

git fetch [<options>] [<remote> [<refspec>...]]

Beschreibung

Der git fetch-Befehl lädt neue Commits, Dateien und Refs aus einem Remote-Repository in Ihr lokales Repo herunter, mergt sie aber NICHT in Ihren Arbeits-Branch. Nach dem Fetchen werden die Remote-Tracking-Refs (wie origin/main) aktualisiert, und Sie können mit git log origin/main prüfen, was es Neues gibt, bevor Sie sich für Merge oder Rebase entscheiden.

Fetchen ist sicher — es modifiziert nie Ihren Working Tree oder den aktuellen Branch. Viele Nutzer bevorzugen git fetch, gefolgt von einem expliziten git merge oder git rebase gegenüber git pull, weil es einen klaren Vorschau-Schritt bietet. Verwenden Sie --all, um von jedem konfigurierten Remote zu fetchen.

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

Häufige Optionen

Option	Beschreibung
--all	Fetcht von allen konfigurierten Remotes.
--prune / -p	Entfernt Remote-Tracking-Refs, die upstream nicht mehr existieren.
--tags	Fetcht alle Tags vom Remote.
--depth=<n>	Begrenzt die gefetchte Historietiefe (erstellt/pflegt einen Shallow Clone).
--unshallow	Konvertiert einen Shallow Clone in einen vollständigen.
--dry-run	Zeigt, was gefetcht würde.
--force / -f	Erlaubt Non-Fast-Forward-Updates von Refs.

Beispiele

git fetch
    # Remote-Tracking-Refs von origin aktualisieren

    git fetch --all --prune
    # Von jedem Remote aktualisieren und veraltete Branches aufräumen

    git fetch upstream main
    # Nur den main-Branch von upstream fetchen

    git fetch --unshallow
    # Vollständige Historie in einen Shallow Clone nachladen

Häufige Fehler

git fetch mit git pull zu verwechseln ist häufig: fetch lädt nur herunter, während pull fetcht und mergt. Das Vergessen von --prune hinterlässt mit der Zeit eine lange Liste veralteter Tracking-Branches. Konfigurieren Sie fetch.prune = true global, um Pruning automatisch zu machen.

Verwandte Befehle

git pull, git merge, git remote, git ls-remote