Der Unterschied zwischen git fetch und git pull 🔄

Beide Befehle holen Daten von einem Remote-Repository (z. B. GitHub), aber sie tun es auf sehr unterschiedliche Weise. Das zu verstehen hilft dir, in verschiedenen Situationen die richtige Entscheidung zu treffen – und verhindert unerwartete Überraschungen in deinem Code.
Das Grundprinzip
Um den Unterschied zu verstehen, ist es wichtig zu wissen, dass Git zwei Dinge getrennt voneinander betrachtet:
Die Informationen über den Zustand des Remote-Repositories – also welche Commits dort existieren
Den tatsächlichen Zustand deiner lokalen Arbeitsdateien – also dein Working Directory und dein lokaler Branch
flowchart TB
    subgraph Remote ["☁️ GitHub"]
        RC["Remote Commits"]
    end
    
    subgraph Lokal ["💻 Dein Computer"]
        TRACK["Remote-Tracking Branch\n(origin/main)"]
        LOCAL["Lokaler Branch\n(main)"]
        WD["Working Directory\nDeine Dateien"]
    end
    
    RC -->|git fetch| TRACK
    TRACK -->|git merge| LOCAL
    LOCAL --> WD
    RC -->|git pull| TRACK
    RC -->|git pull| LOCAL
    RC -->|git pull| WD
git fetch – nur informieren, nichts verändern
Mit 
git fetch holst du dir die neuesten Informationen vom Remote-Repository, aber deine lokalen Branches und Dateien bleiben komplett unverändert. Git aktualisiert lediglich die sogenannten Remote-Tracking-Branches (z. B. 
origin/main), die wie ein Spiegel des Remote-Zustands funktionieren.
Was passiert konkret?
Git verbindet sich mit GitHub und schaut nach, welche neuen Commits es dort gibt
Diese Informationen werden heruntergeladen und in 
origin/main (oder entsprechend 
origin/<branchname>) gespeichert
Dein lokaler 
main-Branch und deine Arbeitsdateien bleiben unangetastet
Typische Ausgabe nach 
git fetch:
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
From github.com:username/projekt
   a1b2c3d..e4f5g6h  main     -> origin/main
Das sagt dir: „Es gibt neue Commits auf GitHub, ich habe sie in 
origin/main gespeichert, aber dein lokaler 
main ist noch auf dem alten Stand."
git pull – informieren und integrieren
git pull ist im Grunde zwei Befehle in einem:
$$
\texttt{git pull} = \texttt{git fetch} + \texttt{git merge}
$$
Es holt also nicht nur die Informationen, sondern führt die Änderungen auch direkt in deinen aktuellen Branch ein. Deine lokalen Dateien werden entsprechend aktualisiert.
Was passiert konkret?
Git führt zunächst einen 
fetch durch
Anschließend werden die neuen Commits automatisch in deinen lokalen Branch gemergt
Dein Working Directory wird aktualisiert – du siehst die Änderungen sofort in deinen Dateien
Typische Ausgabe nach 
git pull:
remote: Enumerating objects: 5, done.
From github.com:username/projekt
   a1b2c3d..e4f5g6h  main     -> origin/main
Updating a1b2c3d..e4f5g6h
Fast-forward
 src/login.php | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)
Wann welchen Befehl verwenden?
Situation
Empfohlener Befehl
Begründung
Du möchtest nur schauen, ob es etwas Neues gibt
git fetch
Keine Änderungen an deinem Code, du behältst die Kontrolle
Du hast ungespeicherte Arbeit und willst nichts riskieren
git fetch
Kein Risiko von Merge-Konflikten mitten in der Arbeit
Du möchtest die Unterschiede analysieren, bevor du aktualisierst
git fetch + manueller Vergleich
Du kannst 
origin/main mit deinem 
main vergleichen
Du bist bereit, die neuesten Änderungen zu übernehmen
git pull
Schnell und praktisch, wenn du weißt, was kommt
Du startest frisch in den Arbeitstag und willst auf dem aktuellen Stand sein
git pull
Holt alles und bringt dich auf den neuesten Stand
Du arbeitest im Team und bist unsicher, was andere geändert haben
git fetch zuerst
Gibt dir die Möglichkeit, Änderungen zu prüfen
💡 Faustregel: Im Zweifel ist 
git fetch die „sicherere" Wahl, weil es deine lokale Arbeit nicht antastet. Du kannst danach immer noch entscheiden, ob und wann du die Änderungen übernimmst.
Der typische Workflow mit 
git fetch
Wenn du vorsichtig vorgehen möchtest, sieht ein typischer Ablauf so aus:
Fetch ausführen – Hole die neuesten Informationen:
git fetch
Vergleichen – Schau dir an, was sich geändert hat:
git log main..origin/main --oneline
Das zeigt dir alle Commits, die auf 
origin/main sind, aber noch nicht in deinem lokalen 
main.
Entscheiden und mergen – Wenn alles gut aussieht:
git merge origin/main
So machst du es in PhpStorm
PhpStorm bietet dir beide Optionen komfortabel über die Benutzeroberfläche an.
Fetch in PhpStorm
Gehe im Menü zu Git → Fetch (oder nutze die Tastenkombination, die du in den Einstellungen findest)
PhpStorm verbindet sich mit GitHub und aktualisiert die Remote-Tracking-Branches
Im Git-Log (unten im Git-Tool-Fenster) siehst du nun, ob 
origin/main weiter ist als dein lokaler 
main
Du erkennst das an einer Anzeige wie „main ← 3 commits behind origin/main"
Pull in PhpStorm
Gehe im Menü zu Git → Pull (oder klicke auf den blauen Pfeil nach unten in der Toolbar)
Es öffnet sich ein Dialog, in dem du auswählen kannst:
Von welchem Remote du pullen möchtest (normalerweise 
origin)
Welchen Branch du holen möchtest
Ob du einen Merge oder Rebase verwenden willst (als Anfänger: bleib bei Merge)
Klicke auf Pull, und PhpStorm holt die Änderungen und integriert sie
Update Project – die komfortable Alternative
PhpStorm bietet auch die Option Git → Update Project (oder 
Ctrl+T / 
Cmd+T). Diese öffnet einen Dialog, der dir verschiedene Optionen gibt:
Merge incoming changes into the current branch – entspricht 
git pull mit Merge
Rebase the current branch on top of incoming changes – fortgeschrittene Option
Du kannst auch wählen, ob PhpStorm vorher automatisch uncommittete Änderungen „stashen" soll
Was passiert bei Konflikten?
Sowohl nach 
git pull als auch nach einem manuellen 
git merge (nach 
fetch) kann es zu Merge-Konflikten kommen, wenn dieselben Stellen in einer Datei unterschiedlich geändert wurden.
Bei 
git fetch allein passiert das nie, weil keine Änderungen integriert werden
Bei 
git pull kann der Konflikt sofort auftreten, und du musst ihn lösen, bevor du weiterarbeiten kannst
PhpStorm zeigt dir Konflikte im Merge-Tool an und hilft dir, sie visuell zu lösen – das kennst du vielleicht schon aus dem Kapitel zu Merge-Konflikten.
Zusammenfassung
Aspekt
git fetch
git pull
Holt Daten vom Remote
✅ Ja
✅ Ja
Ändert deinen lokalen Branch
❌ Nein
✅ Ja
Ändert deine Arbeitsdateien
❌ Nein
✅ Ja
Kann Merge-Konflikte auslösen
❌ Nein
✅ Ja, möglich
Risiko für laufende Arbeit
🟢 Keins
🟡 Mittel
Kontrolle über den Prozess
🟢 Volle Kontrolle
🟡 Automatisiert
🎯 Merke dir: 
git fetch ist wie „Nachrichten lesen, ohne zu antworten" – du informierst dich, ohne dich festzulegen. 
git pull ist wie „Nachrichten lesen und sofort darauf reagieren" – praktisch, aber du solltest wissen, was dich erwartet.