Einführung

git fetch lädt neue Objekte herunter und aktualisiert Remote-Tracking-Refs, ohne Ihren Working Tree zu verändern. git pull macht ein Fetch und integriert dann das Ergebnis in Ihren aktuellen Branch. Den Unterschied zu kennen ist einer der größten Schritte vom Anfänger zum sicheren Git-Nutzer.

Fetchen

git fetch                  # Standard-Remote (üblicherweise origin)
git fetch origin
git fetch --all
git fetch --prune          # Refs löschen, deren Branches auf dem Server gelöscht wurden
git fetch origin main      # nur einen Branch

Nach einem Fetch prüfen Sie, was sich geändert hat:

git log HEAD..origin/main --oneline
git diff HEAD origin/main

Pullen

git pull ist eine Kurzform für Fetch gefolgt von Merge oder Rebase. Wählen Sie die Strategie:

git pull                          # nutzt pull.rebase-Konfiguration
git pull --rebase
git pull --ff-only                # ablehnen, falls kein Fast-Forward
git pull origin main

Standardverhalten konfigurieren

git config --global pull.rebase false   # Merge (klassischer Standard)
git config --global pull.rebase true    # Rebase
git config --global pull.ff only        # nur Fast-Forward
git config --global fetch.prune true

Seit Git 2.27 warnt ein nacktes git pull, wenn keine Strategie konfiguriert ist.

Fetch vs. Pull, wann was

• Verwenden Sie fetch, wenn Sie vor dem Integrieren prüfen wollen.
• Verwenden Sie pull --ff-only, wenn Sie einfach auf einem geteilten Branch aufholen wollen.
• Verwenden Sie pull --rebase, wenn Sie auf einem Topic-Branch arbeiten, den Sie noch nicht gepusht haben.
• Vermeiden Sie schlichtes pull auf langlebigen geteilten Branches; Merge-Commits multiplizieren sich.

Upstream inspizieren

git status
# On branch main
# Your branch is behind 'origin/main' by 3 commits, and can be fast-forwarded.

Diese Nachricht stammt vom Vergleich von HEAD mit dem gecachten origin/main; führen Sie zuerst git fetch aus, damit sie genau ist.

Pull Requests fetchen

Die meisten Git-Hosts stellen Pull- oder Merge-Request-Branches als spezielle Refs bereit, die Sie zur Überprüfung in Ihren Klon fetchen können. Für GitHub fügen Sie eine Refspec hinzu:

git config --add remote.origin.fetch '+refs/pull/*/head:refs/remotes/origin/pr/*'
git fetch
git switch -c review/123 origin/pr/123

Für GitLab ist der äquivalente Pfad refs/merge-requests/*/head. Mit dieser Konfiguration holt jedes git fetch alle offenen PRs lokal, bereit zur Inspektion ohne das Terminal zu verlassen.

Häufige Fehler

git pull mit uncommitted Änderungen ausführen und einen unerwarteten Merge-Commit auf schmutziger Arbeit erhalten. Stashen oder committen Sie zuerst. Vergessen, dass die "behind"-Zählung von git status nur so frisch ist wie der letzte Fetch; wenn niemand seit einer Woche gefetcht hat, lügt diese Zählung. git pull --rebase auf einem Branch verwenden, auf dem andere Arbeit aufgebaut haben, schreibt deren Basis um; rebasen Sie nur auf privaten Branches. Und schließlich: Verwenden Sie git fetch <refspec> niemals mit einer benutzerdefinierten Refspec, ohne sie zu verstehen; ein versehentlicher Doppelpunkt (main:main) überschreibt Ihr lokales main.