Was macht git fetch? Der Befehl verständlich erklärt

git fetch holt den aktuellen Stand eines entfernten Repositorys auf Ihren Rechner, ohne Ihre eigene Arbeit anzufassen. Der Befehl ist damit die risikofreie Art, zu sehen, was Kolleginnen und Kollegen seit Ihrem letzten Stand gepusht haben. Was er verändert und was nicht, welche Optionen im Alltag zählen, wie Sie den geladenen Stand prüfen und übernehmen und wo der Unterschied zu git pull liegt — der Reihe nach.

Was git fetch genau tut

git fetch verbindet sich mit einem entfernten Repository (dem Remote, standardmäßig origin), lädt neue Commit-, Baum- und Blob-Objekte sowie Referenzen herunter und aktualisiert damit die sogenannten Remote-Tracking-Branches. Das sind lokale Zeiger wie origin/main, die den zuletzt bekannten Stand des Remotes abbilden.

Entscheidend: Ihr Arbeitsverzeichnis und Ihre lokalen Branches bleiben unberührt. Git speichert unter .git/refs/remotes/origin/ einen Zeiger je Remote-Branch. git fetch lädt die neuen Objekte herunter und schiebt genau diese Zeiger weiter — an Ihrem Arbeitsstand ändert es nichts. Ihr lokaler Branch main zeigt danach noch auf denselben Commit wie vorher; nur origin/main ist weitergewandert. Es entstehen keine Merge-Konflikte, es werden keine Dateien überschrieben, und nichts an Ihrem uncommitteten Code geht verloren.

Die gebräuchlichsten Aufrufe:

git fetch                # holt vom Standard-Remote (origin)
git fetch origin         # explizit von origin
git fetch origin main    # nur den Branch main
git fetch --all          # von allen konfigurierten Remotes

Welche Remotes überhaupt konfiguriert sind, sehen Sie mit git remote -v.

Den geladenen Stand ansehen und übernehmen

Der eigentliche Nutzen von git fetch entsteht danach: Sie können die neuen Commits in Ruhe prüfen, bevor Sie sie in Ihre Arbeit einfließen lassen.

git log --oneline HEAD..origin/main   # was ist neu auf origin/main?
git diff main origin/main             # welche Zeilen unterscheiden sich?

HEAD..origin/main liest sich als „alle Commits, die auf origin/main, aber noch nicht bei mir liegen“. Sieht alles gut aus, übernehmen Sie die Änderungen mit einem der beiden Wege:

git merge origin/main    # führt zusammen, ggf. mit Merge-Commit
git rebase origin/main   # setzt Ihre Commits sauber oben auf den neuen Stand

Ein reines Vorspulen ohne eigenen offenen Commit läuft dabei als Fast-Forward — was das genau bedeutet, lesen Sie unter /was-ist-git-fast-forward/.

git fetch vs. git pull

Der häufigste Vergleich ist der mit git pull. Die Faustregel:

git pull = git fetch + git merge

git pull holt also erst den neuen Stand und führt ihn im selben Schritt automatisch in Ihren aktuellen Branch zusammen. Das ist bequem, nimmt Ihnen aber die Kontrolle: Wenn der Remote-Stand mit Ihren lokalen Änderungen kollidiert, stehen Sie sofort mitten in einem Merge-Konflikt. Mit git fetch entscheiden Sie selbst, wann und wie integriert wird.

Wer lieber eine lineare Historie möchte, konfiguriert das Zusammenführen auf Rebase um:

git pull --rebase          # einmalig für diesen Aufruf
git config pull.rebase true # dauerhaft für dieses Repository

Mehr dazu, wie git pull mit mehreren Branches umgeht, steht unter /holt-git-pull-alle-branches-ein-ueberblick/; die Abgrenzung „Fetch plus Merge gegenüber Pull“ vertieft der Beitrag /ist-git-fetch-und-merge-dasselbe-wie-pull/.

Wichtige Optionen im Alltag

• --prune (kurz -p): entfernt Remote-Tracking-Branches, die auf dem Server gelöscht wurden. Ohne diese Option bleibt ein längst gelöschter origin/feature-alt bei Ihnen lokal ewig sichtbar. Beispiel: git fetch --prune.
• --tags: holt auch Tags. Standardmäßig lädt git fetch nur Tags, die zu geholten Commits gehören; git fetch --tags holt alle.
• --all: aktualisiert alle Remotes auf einmal, praktisch bei Forks mit origin und upstream.
• --dry-run: zeigt an, was geholt würde, ohne etwas zu ändern — gut zum Prüfen.
• --depth <n>: begrenzt die geholte Historie (Shallow Fetch), nützlich bei sehr großen Repositories oder in CI-Pipelines.

Nach jedem git fetch schreibt Git außerdem die Datei .git/FETCH_HEAD. Sie enthält die zuletzt geholten Referenzen und lässt sich direkt ansprechen, etwa mit git merge FETCH_HEAD.

Ihren lokalen Status vor und nach dem Fetch prüfen Sie mit git status — ausführlich beschrieben unter /wie-ueberpruefe-ich-den-aktuellen-git-status/.

Typische Fehler und ihre Lösung

„fatal: Could not read from remote repository“ Meist ein Authentifizierungsproblem. Prüfen Sie mit git remote -v die Remote-URL. Bei SSH testen Sie den Zugang mit ssh -T git@github.com; bei HTTPS kann ein abgelaufenes Personal Access Token die Ursache sein.

„git fetch hat scheinbar nichts getan“ Das ist oft völlig normal: Wenn der Remote keinen neuen Stand hat, gibt es nichts zu holen. Und selbst bei neuen Commits ändert git fetch bewusst nur die Remote-Tracking-Branches. Prüfen Sie mit git log --oneline origin/main, ob dort tatsächlich Neues angekommen ist.

Ein gelöschter Branch taucht lokal weiter auf Remote-Tracking-Branches verschwinden nicht von selbst. Räumen Sie mit git fetch --prune auf, oder setzen Sie git config remote.origin.prune true, damit jeder Fetch automatisch aufräumt.

„There is no tracking information for the current branch“ Diese Meldung erscheint beim späteren git pull, nicht beim Fetch selbst, wenn Ihr lokaler Branch keinem Remote-Branch zugeordnet ist. Verknüpfen Sie beide mit git branch --set-upstream-to=origin/main.

FAQ

Verändert git fetch meine Dateien oder meinen Branch? Nein. git fetch fasst weder Ihr Arbeitsverzeichnis noch Ihre lokalen Branches an. Es aktualisiert ausschließlich die Remote-Tracking-Branches wie origin/main. Sichtbar in Ihrem Code wird der neue Stand erst nach einem git merge oder git rebase.

Wie oft sollte ich git fetch ausführen? So oft Sie den aktuellen Stand des Teams kennen wollen — der Befehl ist folgenlos und daher unbedenklich. Viele Entwickler fetchen vor Beginn einer Aufgabe und bevor sie einen eigenen Branch pushen, um Überraschungen zu vermeiden. Grafische Werkzeuge tun das oft automatisch im Hintergrund.

Muss ich nach git fetch noch etwas tun, damit die Änderungen ankommen? Ja. Damit die geholten Commits in Ihrem Arbeitszweig landen, führen Sie sie mit git merge origin/<branch> oder git rebase origin/<branch> zusammen. Wer beide Schritte in einem will, nutzt stattdessen direkt git pull.