Git fetch und merge oder git pull: Der Unterschied erklärt

git pull ist keine eigenständige Funktion, sondern eine Abkürzung: intern führt Git nacheinander git fetch und git merge aus. Im Ergebnis machen die drei Befehle dasselbe – der Unterschied liegt darin, wie viel Kontrolle Sie über Zeitpunkt und Art der Zusammenführung behalten. Wer git fetch und git merge einzeln ausführt, kann Remote-Änderungen erst ansehen und dann entscheiden, ob und wie er sie integriert, statt sie sich blind in den laufenden Arbeitsstand ziehen zu lassen. Unten steht, welcher Befehl was tut, wann die getrennte Variante die bessere Wahl ist und wie Sie das oft überraschende Standardverhalten von git pull mit einer einzigen Konfigurationszeile festlegen.

Die kurze Antwort

git pull entspricht dieser Reihenfolge:

git fetch          # Änderungen vom Remote holen
git merge          # sie in den aktuellen Branch einbauen

Wer stattdessen die beiden Einzelbefehle nutzt, bekommt zwischen Schritt 1 und Schritt 2 die Gelegenheit, sich die Änderungen erst anzusehen und dann zu entscheiden, ob und wie er sie integriert. Genau darin besteht der praktische Unterschied.

Was git fetch macht

git fetch lädt alle neuen Commits, Branches und Tags vom entfernten Repository (origin) herunter und aktualisiert damit die sogenannten Remote-Tracking-Branches – also Referenzen wie origin/main. Ihren lokalen Branch und Ihr Arbeitsverzeichnis fasst der Befehl nicht an. Nichts wird zusammengeführt, keine Datei ändert sich, keine offene Arbeit geht verloren.

Nach einem Fetch können Sie den Abstand zwischen Ihrer lokalen Version und dem Remote begutachten:

git fetch origin
git log --oneline HEAD..origin/main   # Commits, die Sie noch nicht haben
git diff HEAD origin/main             # inhaltliche Unterschiede

Fetch ist damit die risikoärmste Operation in Git: Sie holen Informationen, ohne etwas festzulegen. Mehr Details dazu finden Sie unter Was macht git fetch genau?.

Was git merge macht

git merge nimmt die Commits eines anderen Branches – etwa origin/main nach einem Fetch – und baut sie in Ihren aktuellen Branch ein. Wie das geschieht, hängt von der Historie ab:

• Fast-Forward: Haben Sie lokal keine eigenen neuen Commits, verschiebt Git einfach den Branch-Zeiger nach vorne. Es entsteht kein zusätzlicher Commit. Wie das funktioniert, erklärt Was ist ein Git Fast-Forward?.
• Merge-Commit: Haben beide Seiten neue Commits (die Historien sind „auseinandergelaufen”), erzeugt Git einen zusätzlichen Merge-Commit, der beide Stränge verbindet.

Konkret nach einem Fetch:

git merge origin/main

Gibt es an denselben Stellen widersprüchliche Änderungen, entsteht ein Merge-Konflikt – dazu unten mehr.

git pull erledigt beides in einem Schritt

git pull origin main fasst genau diese zwei Aktionen zusammen: erst Fetch, dann Merge des passenden Upstream-Branches in Ihren aktuellen Branch. Für den Alltag ist das bequem und in den meisten Fällen völlig ausreichend – besonders, solange Sie nur einen linearen Verlauf pflegen und Fast-Forwards die Regel sind.

Der Preis der Bequemlichkeit: Sie sehen die fremden Änderungen erst, nachdem sie bereits in Ihrem Branch gelandet sind. Führt der Pull zu einem unerwarteten Merge-Commit oder einem Konflikt mitten in Ihrer laufenden Arbeit, ist das lästiger, als hätten Sie vorher kurz mit git fetch nachgesehen.

Pull mit Rebase statt Merge

git pull kann statt eines Merges auch ein Rebase ausführen. Dabei werden Ihre lokalen Commits „obendrauf” auf den aktuellen Remote-Stand gesetzt, sodass eine geradlinige Historie ohne Merge-Commit entsteht:

git pull --rebase origin main

Das hält die Historie sauber, schreibt aber lokale Commits um – deshalb nur auf Branches verwenden, die Sie noch nicht mit anderen geteilt haben.

Warum die getrennte Variante oft besser ist

Fetch und Merge einzeln auszuführen lohnt sich immer dann, wenn Sie nicht blind übernehmen wollen, was auf dem Remote passiert ist:

1. Sie prüfen vor dem Einbau. Mit git log HEAD..origin/main und git diff sehen Sie genau, was auf Sie zukommt, bevor Sie es in Ihren Branch holen.
2. Sie wählen die Integrationsart bewusst. Merge, Rebase oder erst einmal gar nichts – Sie entscheiden je nach Situation.
3. Sie vermeiden Überraschungen mitten in der Arbeit. Gerade bei einem unfertigen Arbeitsstand ist es angenehmer, den richtigen Moment für den Merge selbst zu bestimmen.

Faustregel: git pull für den schnellen Alltag, git fetch + git merge (oder git rebase), sobald es heikel wird oder mehrere Personen am selben Branch arbeiten.

Standardverhalten von git pull einstellen

Seit Git 2.27 (2020) gibt git pull eine Warnung aus, wenn die Historien auseinandergelaufen sind und Sie nicht konfiguriert haben, ob Git zusammenführen oder rebasen soll. Legen Sie das Verhalten einmal fest, dann ist Ruhe:

# Zusammenführen per Merge-Commit (klassisches Standardverhalten)
git config --global pull.rebase false

# Stattdessen rebasen (lineare Historie)
git config --global pull.rebase true

# Nur Fast-Forward zulassen, sonst abbrechen
git config --global pull.ff only

pull.ff only ist eine defensive und beliebte Einstellung: Ein Pull geht dann nur durch, wenn er ohne Merge-Commit möglich ist. Sobald die Historien auseinanderlaufen, bricht Git ab und Sie entscheiden bewusst über git merge oder git rebase.

Ob ein git pull eigentlich alle Branches oder nur den aktuellen aktualisiert, klärt der Überblick Holt git pull alle Branches ein?.

Typische Fehler und ihre Lösung

„Merge-Konflikt” nach Pull oder Merge. Git markiert die betroffenen Stellen in den Dateien mit <<<<<<<, ======= und >>>>>>>. Lösen Sie den Konflikt von Hand, dann:

git add <datei>
git commit            # bzw. git merge --continue

Wollen Sie den Merge lieber ganz zurücknehmen:

git merge --abort

„fatal: Not possible to fast-forward, aborting.” Diese Meldung erscheint bei pull.ff = only, wenn die Historien auseinandergelaufen sind. Entscheiden Sie sich dann bewusst:

git pull --no-ff      # Merge-Commit erlauben
# oder
git pull --rebase     # lineare Historie

„There is no tracking information for the current branch.” Dem lokalen Branch fehlt der zugeordnete Upstream. Setzen Sie ihn einmalig:

git branch --set-upstream-to=origin/main
# oder beim ersten Push:
git push -u origin main

Unerwarteter Merge-Commit. Wenn nach einem harmlos gemeinten Pull plötzlich ein „Merge branch…”-Commit auftaucht, hatten beide Seiten neue Commits. Wer das vermeiden will, arbeitet mit git pull --rebase oder pull.ff only.

Zum Überprüfen des aktuellen Stands vor jeder dieser Aktionen hilft Wie überprüfe ich den aktuellen Git-Status?.

FAQ

Ist git pull gefährlich? Nicht per se, aber es kombiniert zwei Schritte, sodass Sie fremde Änderungen erst nach dem Einbau sehen. In heiklen Situationen ist git fetch gefolgt von einem geprüften git merge die sicherere Wahl, weil Sie dazwischen kontrollieren können.

Macht git pull immer einen Merge-Commit? Nein. Ist ein Fast-Forward möglich (Sie haben keine eigenen neuen Commits), verschiebt Git nur den Branch-Zeiger, ganz ohne zusätzlichen Commit. Ein Merge-Commit entsteht erst, wenn beide Seiten Commits haben und Sie nicht rebasen.

Wie sehe ich neue Remote-Änderungen, ohne sie zu übernehmen? git fetch ausführen und danach git log HEAD..origin/main bzw. git diff HEAD origin/main betrachten. Ihr lokaler Branch bleibt dabei unverändert – nichts wird zusammengeführt, bis Sie es ausdrücklich anstoßen.