git fetch vs. git pull: Unterschied und wann Sie was verwenden

Die kurze Antwort

git fetch lädt neue Commits vom Server herunter und aktualisiert die Referenzen der Remote-Branches (origin/main, origin/feature-x), verändert aber weder Ihren aktuellen Branch noch die Dateien im Arbeitsverzeichnis. git pull ist git fetch plus das sofortige Zusammenführen des Heruntergeladenen mit dem aktuellen Branch: per Merge (Standard) oder per Rebase.

Daraus folgt eine praktische Regel: Fetch können Sie jederzeit ausführen, er macht nichts kaputt. Pull verändert Ihren Branch und kann mit einem Konflikt enden. Führen Sie ihn deshalb mit sauberem Arbeitsverzeichnis aus und mit einer Vorstellung davon, was gleich hereinkommt.

Wo Remote-Branches leben

Damit der Unterschied offensichtlich wird, müssen Sie wissen, dass es im lokalen Repository zwei Arten von Branches gibt. Lokale Branches – main, feature-x – bewegen Sie selbst mit Ihren Commits. Remote-Tracking-Branches – origin/main – sind Lesezeichen nach dem Motto „so sah der Server bei der letzten Synchronisation aus“. Von Hand lassen sie sich nicht verschieben; aktualisiert werden sie nur durch die Kommunikation mit dem Server: fetch, pull und push.

git branch -a
* main
  remotes/origin/HEAD -> origin/main
  remotes/origin/main
  remotes/origin/feature-x

git status vergleicht Ihren Branch genau mit dem Lesezeichen origin/main, nicht mit dem echten Server. Deshalb kann die Meldung „Your branch is up to date with 'origin/main'“ täuschen: Haben Sie lange kein fetch gemacht, weiß Git schlicht nichts von den neuen Commits Ihrer Kollegen.

Was git fetch macht

$ git fetch
remote: Enumerating objects: 7, done.
remote: Counting objects: 100% (7/7), done.
Unpacking objects: 100% (4/4), done.
From github.com:team/project
   3f2a1c9..8b7d4e2  main       -> origin/main

Die letzte Zeile sagt das Wichtigste: Die Referenz origin/main wurde von 3f2a1c9 auf 8b7d4e2 verschoben. Ihr main ist an Ort und Stelle geblieben. Jetzt können Sie in Ruhe ansehen, was angekommen ist:

git status                       # Your branch is behind 'origin/main' by 2 commits
git log main..origin/main --oneline   # Commits, die Sie noch nicht haben
git diff main origin/main        # was sich in den Dateien ändern wird

Nützliche Varianten von fetch:

• git fetch --all – Änderungen von allen Remotes holen (relevant, wenn ein Fork origin und upstream hat);
• git fetch --prune (-p) – lokale Lesezeichen von Branches entfernen, die es auf dem Server nicht mehr gibt;
• git fetch origin main – nur einen einzigen Branch holen;
• git fetch --tags – zusätzlich alle Tags holen.

Damit das Pruning immer greift, schalten Sie es einmalig ein: git config --global fetch.prune true.

Was git pull macht

git pull führt zwei Schritte nacheinander aus. Zuerst ein fetch für den Upstream des aktuellen Branches, dann das Zusammenführen von origin/<branch> mit Ihrem Branch. Wörtlich entspricht das:

git fetch origin
git merge origin/main      # oder git rebase origin/main bei pull --rebase

Das Ergebnis hängt davon ab, wie die Historien auseinandergelaufen sind:

• Sie haben keine neuen Commits – es gibt einen Fast-Forward, der Branch wird einfach vorgespult;
• neue Commits gibt es sowohl bei Ihnen als auch auf dem Server – beim Merge entsteht ein Merge-Commit, beim Rebase werden Ihre Commits auf die Server-Commits gesetzt;
• dieselben Zeilen wurden auf beiden Seiten geändert – ein Konflikt, den Sie manuell lösen müssen.

git fetch und git pull im Vergleich

git pull: Merge oder Rebase?

Seit Git 2.27 gibt pull bei auseinandergelaufener Historie ohne explizite Einstellung eine Warnung aus, und neuere Versionen brechen statt eines stillen Merges mit dem Fehler „Need to specify how to reconcile divergent branches“ ab. Git bittet Sie, einmalig eine Strategie zu wählen:

git config --global pull.rebase false   # Merge (früheres Standardverhalten)
git config --global pull.rebase true    # Rebase
git config --global pull.ff only        # nur Fast-Forward, sonst Abbruch

Merge erhält die Historie, wie sie war, und fügt einen Commit „Merge branch 'main' of github.com:...“ hinzu. Wenn Sie jeden Tag in einen Branch mit lokalen Commits pullen, wuchert die Historie mit solchen technischen Merges zu.

Rebase setzt Ihre noch nicht gepushten Commits auf die frischen Server-Commits. Die Historie bleibt linear, und Konflikte werden Commit für Commit gelöst. Für unveröffentlichte lokale Commits ist das meist die beste Wahl. Gefährlich ist Rebase nur bei bereits gepushten Commits, auf denen andere aufbauen.

ff only ist der strengste Modus: pull klappt nur, wenn Sie keine eigenen Commits haben. Ist die Historie auseinandergelaufen, entscheiden Sie bewusst, was zu tun ist. Viele erfahrene Entwickler stellen genau diesen Modus für die Hauptbranches ein.

Haben Sie nicht committete Änderungen im Arbeitsverzeichnis und brauchen den Pull trotzdem sofort, hilft git pull --rebase --autostash: Git legt die Änderungen beiseite, führt den Rebase aus und spielt sie danach wieder zurück.

Typischer Ablauf: fetch, prüfen, zusammenführen

Der Ansatz „erst fetch“ gibt Ihnen Kontrolle darüber, was in Ihren Branch gelangt. Besonders nützlich ist er vor einem Pull Request und nach einer längeren Pause.

git fetch
git log --oneline --graph HEAD origin/main   # wie die Branches auseinandergelaufen sind
git rebase origin/main                       # oder git merge origin/main
git push

Ein weiterer häufiger Fall: den eigenen Feature-Branch mit dem aktuellen main aktualisieren, ohne dorthin zu wechseln:

git switch feature-x
git fetch
git rebase origin/main

Pull passt hier nicht: git pull im Feature-Branch holt die Änderungen seines eigenen Upstreams (origin/feature-x), nicht des Hauptbranches. Sie könnten natürlich git pull --rebase origin main schreiben, aber die Variante mit fetch ist übersichtlicher.

Mit dem Server synchronisieren: den Branch aktuell halten

Mit „git sync“ ist meist der Kreislauf „Fremdes holen – Eigenes senden“ gemeint. Im reinen Git gibt es keinen eigenen sync-Befehl (einen Sync-Button gibt es in IDEs und GUI-Clients, intern macht er pull und danach push). Von Hand sieht ein zuverlässiger Ablauf so aus:

1. git status – sicherstellen, dass alles committet oder per git stash beiseitegelegt ist;
2. git pull --rebase – Änderungen holen und die eigenen Commits obendrauf setzen;
3. Konflikte lösen, falls vorhanden: Dateien korrigieren, git add, git rebase --continue;
4. Tests laufen lassen;
5. git push.

Einen Fork mit dem Original-Repository synchronisieren Sie so:

git remote add upstream https://github.com/original/project.git
git fetch upstream
git switch main
git merge --ff-only upstream/main
git push origin main

Häufige Probleme mit git pull

Your local changes would be overwritten by merge

Pull will Dateien ändern, die Sie gerade bearbeiten und nicht committet haben. Optionen: committen, beiseitelegen (git stash, dann pull und git stash pop) oder --autostash verwenden. Ihre Änderungen für einen Pull zu verwerfen, ist nicht nötig.

Konflikt nach git pull

Git hält an und zeigt die Dateien mit Konflikt in git status. Öffnen Sie sie, wählen Sie die passende Variante zwischen den Markern <<<<<<< und >>>>>>>, dann git add und git commit (bei Merge) oder git rebase --continue (bei Rebase). Haben Sie es sich anders überlegt, stellen git merge --abort oder git rebase --abort den Zustand vor dem Pull wieder her.

There is no tracking information for the current branch

Für den Branch ist kein Upstream eingerichtet, und Git weiß nicht, woher es ziehen soll. Geben Sie es explizit an: git pull origin main, oder richten Sie die Verknüpfung einmalig ein: git branch --set-upstream-to=origin/main.

refusing to merge unrelated histories

Lokales und Remote-Repository wurden unabhängig voneinander angelegt, etwa weil beim Erstellen auf dem Server eine README hinzugefügt wurde. Wenn Sie sicher sind, dass beide zusammengeführt werden sollen: git pull origin main --allow-unrelated-histories.

Missglückter Pull: so machen Sie ihn rückgängig

Ist der Merge nach dem Pull bereits abgeschlossen und das Ergebnis passt nicht, setzen Sie den Branch auf den Zustand davor zurück: git reset --hard ORIG_HEAD. Der Befehl löscht nicht committete Änderungen, prüfen Sie also vorher git status. Im Notfall finden Sie die frühere Position des Branches in git reflog.

Was sollten Sie wählen?

• Sie wollen wissen, was es Neues gibt, ohne etwas zu ändern – git fetch.
• Sie arbeiten in Ihrem eigenen Branch und schließen nur zum Server auf – git pull --rebase (oder pull mit eingestelltem pull.rebase true).
• Sie aktualisieren den Hauptbranch ohne eigene Commits – git pull --ff-only.
• Sie müssen main in einen Feature-Branch übernehmen – git fetch und danach git rebase origin/main oder git merge origin/main.
• Sie schreiben ein Skript oder eine CI-Pipeline – fetch und explizite Befehle, ohne pull.

So sieht es im Commit-Graphen aus

Stellen Sie sich vor, Sie und ein Kollege haben beim Commit C angefangen. Sie haben lokal den Commit D erstellt, der Kollege hat E auf den Server gepusht. Nach git fetch kennt Ihr Repository beide Linien: main zeigt auf D, origin/main auf E, und beide haben den gemeinsamen Vorfahren C.

          D   <- main (HEAD)
         /
A---B---C
         \
          E   <- origin/main

Alles Weitere entscheidet die Art der Zusammenführung. git merge origin/main erzeugt einen Commit M mit den zwei Eltern D und E. git rebase origin/main kopiert D als neuen Commit D' mit anderem Hash auf E, und die Historie wird zu einer geraden Linie. git pull führt genau diese Schritte automatisch aus, ohne Pause dazwischen. Gerade diese Pause – die Möglichkeit, den Graphen vor dem Zusammenführen anzusehen – ist der eigentliche Wert eines separaten fetch.

Fetch und Pull in der IDE

In VS Code, IntelliJ IDEA und anderen Editoren heißen die Buttons unterschiedlich, dahinter stecken aber dieselben Befehle. „Fetch“ ist git fetch, „Pull“ oder „Update Project“ ist pull mit der in den Einstellungen gewählten Strategie (Merge oder Rebase), „Sync Changes“ ist pull und danach push. Bevor Sie in einem gemeinsamen Branch auf Sync klicken, sollten Sie wissen, welche Strategie eingestellt ist – sonst tauchen in der Historie unerwartet Merge-Commits auf. Viele IDEs führen fetch außerdem regelmäßig im Hintergrund aus, daher ist der Zähler eingehender Commits in der Statusleiste meist aktuell.

Fazit

git fetch aktualisiert Ihr Wissen über den Server, git pull wendet dieses Wissen zusätzlich auf den aktuellen Branch an. Fetch ist jederzeit sicher; pull ist bequem, verändert aber den Branch und kann Konflikte bringen. Stellen Sie daher einmalig seine Strategie ein und halten Sie das Arbeitsverzeichnis sauber. Den Unterschied zwischen push, pull und fetch, die Arbeit mit Remotes und GitHub üben Sie praktisch im Git-Kurs.