Einführung

git pull ist Zucker für git fetch gefolgt von der Integration des Upstream-Branches in den aktuellen Branch. Der Integrationsschritt ist entweder ein Merge (Standard) oder ein Rebase.

Die zwei Schritte

1. git fetch <remote> <refspec>: herunterladen und Tracking-Refs aktualisieren.
2. Wenn pull.rebase false ist: git merge FETCH_HEAD.
3. Wenn pull.rebase true ist: git rebase FETCH_HEAD.

Äquivalente manuelle Sequenz:

git fetch origin main
git merge origin/main             # oder git rebase origin/main

Konfiguration

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, sonst Abbruch

Seit Git 2.27 gibt ein einfaches git pull ohne Konfiguration eine Warnung aus. Wählen Sie eine Strategie ausdrücklich.

Nur Fast-Forward

--ff-only ist der sicherste Pull: Er gelingt nur, wenn Ihr Branch strikt zurück ist. Kein Merge-Commit, kein Rebase, keine Überraschungen.

git pull --ff-only

Kombinieren Sie mit Autostash, um Working-Tree-Blocker zu vermeiden:

git pull --ff-only --autostash

Pull mit Rebase

git pull --rebase
git pull --rebase=merges          # Merge-Struktur erhalten

--rebase=merges ist nützlich für Branches, die Merge-Commits enthalten, die Sie behalten möchten.

Pull mit Autostash

git config --global rebase.autoStash true
git config --global merge.autoStash true

Mit diesen aktiviert werden schmutzige Trees vor der Integration gestasht und danach transparent wieder angewendet.

Multi-Branch-Pull

git pull origin main feature        # fetcht beide, mergt Octopus in HEAD

Das ist selten gewünscht; bevorzugen Sie separate Operationen.

Pull vs. expliziter Fetch + Integration

Viele erfahrene Nutzer ziehen es vor, git pull nie zu verwenden. Sie führen zuerst git fetch aus, prüfen git log HEAD..@{u} und wählen dann bewusst Merge oder Rebase. Dies ist besonders wertvoll beim Integrieren langlebiger divergenter Branches.

Pull-Richtlinien für Teams

Gesunde Teams wählen eine einzelne Pull-Richtlinie und konfigurieren sie organisationsweit. Zwei häufige Wahlmöglichkeiten:

# Lineare-Historie-Team: beim Pull rebasen, Merge nur via PR
git config --global pull.rebase true
git config --global rebase.autoStash true

# Merge-freundliches Team: nie rebasen, immer fast-forward für main
git config --global pull.rebase false
git config --global pull.ff only

Die schlechteste Konfiguration ist die fehlende: Jeder Entwickler-git pull verhält sich anders und erzeugt inkonsistente Historien. Dokumentieren Sie die Richtlinie in der CONTRIBUTING.md Ihres Repositories und stellen Sie ein einzeiliges Konfigurations-Snippet bereit, das neue Mitwirkende kopieren können.

Häufige Fehler

git pull mit uncommitted Änderungen ausführen und einen unerwarteten Merge-Commit auf schmutziger Arbeit erhalten. Stashen, committen oder autoStash setzen. Mit Rebase auf einem Branch pullen, auf dem andere Arbeit aufgebaut haben; Sie schreiben deren Basis um. Rebasen Sie nur auf privaten Branches. pull.rebase global konfigurieren, ohne zu merken, dass es auch main betrifft; viele Teams setzen pull.ff only global und überschreiben pro Branch. Schließlich: git pull in CI verwenden; CI braucht selten Integration, nur den neuesten Commit. Verwenden Sie git fetch und ein explizites Auschecken von origin/main, um CI deterministisch zu halten.