Weswegen
Tippen, um zu suchen
    Esc zum Schließen · Sofortsuche auf der ganzen Website

    Was macht git fetch genau? Der Befehl erklärt

    · Weswegen-Redaktion
    Programmierung

    git fetch holt alle neuen Commits, Branches und Tags aus einem entfernten Repository herunter – und rührt Ihre Arbeitskopie dabei nicht an. Genau das ist der Punkt, den viele beim Umstieg von git pull unterschätzen: Nach einem fetch sieht Ihr Arbeitsverzeichnis exakt so aus wie vorher. Sie bekommen die Änderungen zunächst nur zum Ansehen, nicht zum Einbauen. Was der Befehl technisch macht, wie Sie das heruntergeladene Ergebnis inspizieren und wann fetch die sicherere Wahl als pull ist, klären die nächsten Abschnitte.

    Was git fetch technisch tut

    Wenn Sie git fetch ausführen, baut Git eine Verbindung zum konfigurierten Remote (standardmäßig origin) auf und lädt alle Objekte herunter, die lokal noch fehlen. Aktualisiert werden dabei die sogenannten Remote-Tracking-Branches. Das sind Referenzen im Namensraum refs/remotes/, die Sie als origin/main, origin/develop und so weiter kennen.

    Entscheidend: Ihre lokalen Branches (main, develop, …) bleiben unverändert. Auch der HEAD, der Index und die Dateien im Arbeitsverzeichnis bleiben, wie sie sind. fetch verschiebt nur die origin/*-Zeiger nach vorn und speichert die neuen Commit-Objekte im lokalen .git-Verzeichnis.

    Ein Standardaufruf sieht so aus:

    git fetch origin

    Die Ausgabe listet die aktualisierten Referenzen auf, etwa:

    From github.com:firma/projekt
   a1b2c3d..e4f5a6b  main       -> origin/main
 * [new branch]      feature/x  -> origin/feature/x

    Der Pfeil -> zeigt genau das an: Der Remote-Branch main landet lokal als origin/main. Ihr eigener main taucht in dieser Ausgabe gar nicht auf, weil er nicht angefasst wird.

    Warum fetch statt pull

    git pull ist praktisch eine Abkürzung für git fetch plus git merge (oder git rebase, je nach Konfiguration). pull lädt also nicht nur herunter, sondern führt die Änderungen sofort in Ihren aktuellen Branch ein. Das ist bequem, aber Sie geben die Kontrolle darüber ab, was genau in Ihre Arbeit einfließt.

    git fetch trennt diese beiden Schritte. Der Nutzen in der Praxis:

    • Sie sehen zuerst, was kommt. Vor dem Zusammenführen können Sie prüfen, welche Commits neu sind und ob es Konflikte geben wird.
    • Kein überraschender Merge. Bei pull starten Sie manchmal ungewollt einen Merge-Commit oder landen in einem Konflikt, ohne es geplant zu haben.
    • Sicher bei geteilten Branches. Wenn mehrere Leute am selben Branch arbeiten, sehen Sie mit fetch erst die fremden Commits, bevor Sie entscheiden, ob Sie mergen oder rebasen.

    Seit Git 2.27 verstärkt der Befehl selbst diesen Punkt: Wenn git pull weder vor- noch zurückspulen kann (divergierende Historien) und keine Strategie konfiguriert ist, bricht Git mit einer Warnung ab und verlangt eine bewusste Entscheidung – etwa git config pull.rebase false (Merge), true (Rebase) oder git config pull.ff only (nur Fast-Forward). Wer stattdessen fetcht, umgeht diese Frage, weil merge und rebase ohnehin getrennt und explizit erfolgen.

    Kurz: fetch ist die vorsichtige, reversible Variante. Solange Sie nur fetchen, kann an Ihrer Arbeit nichts kaputtgehen.

    Änderungen nach dem Fetch ansehen

    Der eigentliche Wert von fetch entsteht durch das, was Sie danach tun: nachschauen, bevor Sie zusammenführen. Ein paar nützliche Befehle:

    # Welche Commits hat origin/main, die mein main noch nicht hat?
git log main..origin/main --oneline

# Grafische Übersicht über lokale und Remote-Branches
git log --oneline --graph --all

# Konkrete Datei-Unterschiede zwischen lokal und Remote
git diff main origin/main

    Die Syntax main..origin/main bedeutet „alle Commits, die in origin/main, aber nicht in main enthalten sind”. So sehen Sie exakt, was ein späterer Merge oder Rebase hereinholen würde.

    Erst wenn Sie zufrieden sind, führen Sie die Änderungen bewusst ein:

    git merge origin/main     # führt zusammen (ggf. Merge-Commit)
# oder
git rebase origin/main    # setzt Ihre Commits oben drauf, lineare Historie

    Wer die Historie lieber linear hält, greift zum Rebase. Wer den Verlauf mit Merge-Commits nachvollziehbar dokumentieren will, bleibt beim Merge. Beides setzt voraus, dass Sie vorher gefetcht haben.

    Nützliche Optionen für git fetch

    Der Befehl kann mehr als nur den Standardfall. Diese Optionen brauchen Sie im Alltag am häufigsten:

    • git fetch --all holt Änderungen von allen konfigurierten Remotes, nicht nur von origin. Praktisch, wenn Sie mit einem Fork und dem Original-Upstream arbeiten.
    • git fetch --prune (kurz -p) räumt auf: Remote-Tracking-Branches, die auf dem Server gelöscht wurden, verschwinden auch lokal. Ohne --prune sammeln sich sonst „Karteileichen” wie origin/alter-feature-branch an, die es remote längst nicht mehr gibt.
    • git fetch --tags lädt zusätzlich alle Tags herunter. Standardmäßig holt Git nur Tags, die zu den gefetchten Commits gehören.
    • git fetch origin main beschränkt den Abruf auf einen einzelnen Branch – nützlich bei sehr großen Repositories.

    Ein bewährter Alltagsbefehl, der gleich aufräumt:

    git fetch --all --prune

    Damit haben Sie den vollständigen, aktuellen Stand aller Remotes und keine veralteten Branch-Referenzen im Weg.

    Typische Fehler und wie Sie sie lösen

    „Ich habe gefetcht, sehe aber keine Änderungen in meinen Dateien.” Das ist kein Fehler, sondern gewolltes Verhalten. fetch verändert Ihre Dateien nicht. Die neuen Commits liegen in origin/main. Führen Sie sie mit git merge origin/main oder git rebase origin/main ein, oder verwenden Sie gleich git pull.

    fatal: 'origin' does not appear to be a git repository Es ist kein Remote namens origin konfiguriert. Prüfen Sie mit git remote -v, welche Remotes existieren, und legen Sie ihn bei Bedarf an:

    git remote add origin https://github.com/firma/projekt.git

    Authentifizierung schlägt fehl (HTTPS). GitHub, GitLab und Bitbucket akzeptieren seit Jahren keine Konto-Passwörter mehr über HTTPS. Verwenden Sie ein Personal Access Token statt des Passworts oder stellen Sie das Repository auf SSH um.

    origin/main zeigt einen alten Stand. Meist wurde nur ein anderer Branch gefetcht oder die Verbindung war unterbrochen. Ein erneutes git fetch origin mit Blick auf die Ausgabe zeigt, ob und was aktualisiert wurde.

    Wie oft sollte man fetchen?

    Es schadet nie, oft zu fetchen. Der Befehl ist rein lesend, verändert nichts an Ihrer Arbeit und verhindert, dass Sie stundenlang auf einem veralteten Stand entwickeln. Viele Entwickler starten den Arbeitstag mit git fetch --all --prune, um den Überblick über das Team zu bekommen, bevor sie eigene Commits pushen.

    Wer tiefer einsteigen will: Was ein Fast-Forward-Merge technisch bedeutet und ob git pull wirklich dasselbe wie fetch plus merge ist, klären zwei weiterführende Artikel.

    FAQ

    Verändert git fetch meine lokalen Dateien? Nein. fetch aktualisiert ausschließlich die Remote-Tracking-Branches (origin/*) und lädt neue Objekte in .git. Ihr Arbeitsverzeichnis, Ihr Index und Ihre lokalen Branches bleiben unangetastet. Erst ein anschließendes merge, rebase oder pull ändert Ihre Dateien.

    Was ist der Unterschied zwischen git fetch und git pull? git pull ist git fetch gefolgt von git merge (oder git rebase). fetch holt die Änderungen nur herunter, pull baut sie sofort in Ihren aktuellen Branch ein. Wer erst prüfen will, nimmt fetch; wer die Änderungen direkt übernehmen will, nimmt pull.

    Wie sehe ich, was git fetch heruntergeladen hat? Mit git log main..origin/main --oneline sehen Sie die neuen Commits, mit git diff main origin/main die konkreten Datei-Unterschiede. Ersetzen Sie main durch den jeweiligen Branch-Namen.