git pull
Von einem anderen Repository oder lokalen Branch holen und integrieren
Der Befehl 'git pull' holt Inhalte aus einem Remote-Repository und integriert sie sofort in deinen lokalen Branch. Im Kern ist das 'git fetch' gefolgt von 'git merge' (oder 'git rebase' mit der Option --rebase). Das ist der übliche Weg, dein lokales Repository mit den Änderungen anderer zu synchronisieren. Bei git pull lädt Git zuerst alle neuen Commits vom Remote herunter und integriert sie dann in deinen aktuellen Branch. Ist dein Branch nur im Rückstand, spult es per Fast-Forward vor; haben beide Seiten neue Commits, hält modernes Git an und lässt dich zwischen Merge und Rebase wählen (--no-rebase / --rebase oder die Einstellung pull.rebase). Gibt es kollidierende Änderungen, hält Git an und bittet dich, die Konflikte zu lösen, bevor der Merge abgeschlossen wird.
Syntax
git pull [--rebase | --no-rebase] [--ff-only | --ff | --no-ff] [--commit | --no-commit] [--autostash | --no-autostash] [-q | --quiet] [-v | --verbose] [--depth=<depth>] [--prune] [--tags | --no-tags] [--recurse-submodules[=yes|on-demand|no]] [<repository> [<refspec>...]]Optionen
Die richtige Option wählen
Pull-Strategie: Merge oder Rebase
Die grundlegende Wahl, die deine Commit-Historie prägt
| Befehl | Erzeugt Merge-Commit | Art der Historie | Am besten für |
|---|---|---|---|
git pull | Hängt von der Konfiguration ab (scheitert bei Abweichung ohne Einstellung) | Gesetzt über pull.rebase / pull.ff | Fast-Forward, wenn nur im Rückstand |
git pull --rebase | No | Linear | Feature-Branches, saubere Historie |
git pull --no-rebase | Ja (bei Abweichung) | Bewahrt Branches | Rebase-Konfiguration übergehen, Merge erzwingen |
git pull --ff-only | No | Linear (scheitert bei Abweichung) | Sicherstellen, dass keine versehentlichen Merges entstehen |
Sicherheits- und Kontrolloptionen
Optionen, um Fehler zu vermeiden und die Kontrolle zu behalten
| Befehl | Verhindert | Verhalten | Wann verwenden |
|---|---|---|---|
--ff-only | Unerwartete Merges | Scheitert, wenn kein Fast-Forward möglich ist | CI/CD, geschützte Branches |
--no-commit | Auto-Commit | Mergt, hält aber vor dem Commit an | Merge vor dem Commit prüfen |
--autostash | Fehler durch geändertes Arbeitsverzeichnis | Stash → pull → pop | Schneller Sync mit nicht committeter Arbeit |
--dry-run | Beliebige Änderungen | Zeigt, was fetch herunterladen würde; kein Merge | Vorschau eingehender Refs |
Was geholt wird
Steuern, welche Refs und wie viel Historie heruntergeladen werden
| Befehl | Holt Tags | Holt die ganze Historie | Anwendungsfall |
|---|---|---|---|
git pull | Auto (gefolgte Tags) | Ja | Normaler Workflow |
--tags | Alle Tags | Ja | Release-Versionen synchronisieren |
--no-tags | No | Ja | Bandbreite sparen, nur Branch synchronisieren |
--depth=N | Auto (gefolgte Tags) | Nur die letzten N Commits | Große Repos, CI-Builds |
--unshallow | Auto (gefolgte Tags) | Macht aus flach vollständig | Nach einem Shallow Clone die ganze Historie nötig |
Remote- und Branch-Verwaltung
Optionen für mehrere Remotes und veraltete Refs
| Befehl | Umfang | Räumt auf | Szenario |
|---|---|---|---|
git pull origin main | Ein Remote/Branch | No | Normaler Pull von origin |
--all | Alle Remotes | No | Von origin + upstream synchronisieren |
--prune | Ein Remote | Gelöschte Branches | Veraltete Tracking-Refs entfernen |
Fortgeschrittene Szenarien
Optionen für komplexe oder ungewöhnliche Situationen
| Befehl | Löst | Risiko | Typisches Szenario |
|---|---|---|---|
--allow-unrelated-histories | Kein gemeinsamer Vorfahre | Mittel | Zwei getrennte Repos mergen |
-s <strategy> | Besondere Merge-Anforderungen (verhindert keine Konflikte) | Niedrig | Einen bestimmten Merge-Algorithmus erzwingen |
--recurse-submodules | Veraltete Submodule | Niedrig | Projekte mit Git-Submodulen |
Workflow-Beispiele
git statusNach nicht committeten Änderungen sehen, die kollidieren könnten
git stashNicht committete Arbeit bei Bedarf stashen (oder --autostash nutzen)
git pull --rebase origin mainMit Rebase pullen, damit die Historie sauber bleibt
git stash popDie gestashte Arbeit wiederherstellen, falls du vorher gestasht hast
git checkout feature-branchAuf deinen Feature-Branch wechseln
git pull --no-rebase origin mainDen neuesten main in deinen Feature-Branch mergen (ausdrücklich, da die Branches abgewichen sind)
git push origin feature-branchDen aktualisierten Feature-Branch pushen
git fetch originRemote-Änderungen herunterladen, ohne das Arbeitsverzeichnis zu ändern
git log HEAD..origin/mainSehen, welche Commits du gleich pullst
git diff HEAD...origin/mainDie Änderungen auf dem Remote prüfen
git pull origin mainPullen, wenn du mit den Änderungen zufrieden bist
git pull --no-rebase origin mainEinen Pull per Merge versuchen – kann Konflikte ergeben
git statusSehen, welche Dateien Konflikte haben (als 'both modified' markiert)
(edit conflicted files)Dateien öffnen und die Konfliktmarker (<<<<<<<, =======, >>>>>>>) auflösen
git add <resolved-files>Die gelösten Dateien stagen
git commitDen Merge mit einem Commit abschließen
git pull --rebase --autostash origin mainÄnderungen automatisch stashen, pullen und wieder anwenden
Fehlerbehebung
Your local changes would be overwritten by merge
Ursache: Du hast nicht committete Änderungen in Dateien, die der Pull ändern würde
Committe deine Änderungen zuerst (git add . && git commit), stashe sie (git stash) oder nutze git pull --rebase --autostash
git stash && git pull && git stash popRefusing to merge unrelated histories
Ursache: Remote- und lokales Repository haben keinen gemeinsamen Vorfahren (z. B. beim Pull in ein frisch initialisiertes Repo)
Das Mergen unabhängiger Historien erlauben – üblich, wenn man einem bestehenden lokalen Repo ein Remote hinzufügt
git pull --allow-unrelated-histories origin mainMerge-Konflikt in Datei(en)
Ursache: Du und das Remote habt dieselben Zeilen einer Datei geändert
Öffne die Konfliktdateien, suche die Marker (<<<<<<<, =======, >>>>>>>), löse sie, dann git add und git commit. Oder brich mit git merge --abort ab
git add <resolved-file> && git commitNot possible to fast-forward, aborting
Ursache: Du hast --ff-only genutzt (oder pull.ff=only ist gesetzt), aber dein lokaler Branch ist vom Remote abgewichen
Nutze stattdessen Rebase (git pull --rebase) oder erlaube einen Merge-Commit (git pull --no-rebase)
git pull --rebase origin mainCannot pull with rebase: You have unstaged changes
Ursache: Ein Pull mit Rebase braucht einen sauberen Arbeitsbaum, und du hast nicht committete Änderungen
Committe oder stashe deine Änderungen, oder nutze Autostash, damit das automatisch passiert
git pull --rebase --autostashNo tracking information for the current branch
Ursache: Dein Branch ist nicht so eingerichtet, dass er einem Remote-Branch folgt
Setze den Upstream-Branch ausdrücklich oder gib Remote und Branch im Pull-Befehl an
git branch --set-upstream-to=origin/main main'origin' does not appear to be a git repository
Ursache: Es ist kein Remote namens 'origin' konfiguriert
Prüfe deine Remotes mit git remote -v und füge origin hinzu oder nutze den richtigen Remote-Namen
git remote add origin <url>You have divergent branches and need to specify how to reconcile them
Ursache: Beide Seiten haben neue Commits, und weder pull.rebase noch pull.ff ist gesetzt – also weigert sich modernes Git zu raten (ältere Versionen ab 2.27 warnten nur)
Gib Merge (--no-rebase) oder Rebase (--rebase) an oder lege mit git config pull.rebase einen Standard fest
git config --global pull.rebase trueTipps & Stolperfallen
Best Practices
- ✓Prüfe vor dem Pull immer git status, um Konflikte mit nicht committeten Änderungen zu vermeiden
- ✓Nutze git pull --rebase, damit die Historie auf Feature-Branches sauber und linear bleibt
- ✓Setze pull.rebase=true global, wenn du Rebase als Standard willst: git config --global pull.rebase true
- ✓Nutze zuerst git fetch, wenn du Änderungen vor dem Integrieren prüfen willst
- ✓Nutze --ff-only, wenn du sichergehen willst, dass nicht versehentlich Merge-Commits entstehen
- ✓Richte beim ersten Push mit git push -u das Branch-Tracking ein, das vereinfacht spätere Pulls
- ✓Nutze --autostash, wenn du nicht committete Änderungen hast, aber schnell pullen musst
- ✓Pulle main/master regelmäßig, um später große, komplexe Merges zu vermeiden
- ✓Löse Konflikte sofort – lass dein Repository nie im Konfliktzustand
- ✓Nutze git pull --prune, um veraltete Remote-Tracking-Branches aufzuräumen
- ✓Nutze eventuell git fetch + git merge, um mehr Kontrolle über die Integration zu haben
- ✓Prüfe vor dem Pull immer, dass du auf dem richtigen Branch bist, damit keine Änderungen vermischt werden
Häufige Fehler
- ✗Mit nicht committeten Änderungen pullen: Das kann Merge-Konflikte verursachen oder ganz scheitern. Committe oder stashe deine Änderungen vorher, oder nutze --autostash, damit das automatisch passiert.
- ✗pull und fetch nicht auseinanderhalten: 'git pull' mergt automatisch, was überraschen kann. Nutze zuerst 'git fetch', wenn du Änderungen vor dem Integrieren prüfen willst.
- ✗merge nutzen, wo rebase sauberer wäre: Auf Feature-Branches erzeugt 'git pull --rebase' eine saubere lineare Historie ohne unnötige Merge-Commits.
- ✗Merge-Konflikte ignorieren: Nach einem Pull mit Konflikten musst du sie lösen und committen. Lass dein Repository nie im Konfliktzustand.
- ✗In den falschen Branch pullen: Prüfe vor dem Pull immer deinen aktuellen Branch mit 'git status'. In main zu pullen, obwohl du einen Feature-Branch meintest, kann Probleme machen.
FAQ
git fetch lädt nur neue Commits vom Remote herunter, ohne dein Arbeitsverzeichnis oder deine lokalen Branches zu ändern. git pull macht einen Fetch UND mergt (oder rebast) diese Änderungen automatisch in deinen aktuellen Branch. Nutze fetch, wenn du Änderungen vor dem Integrieren prüfen willst.
Nutze --rebase, wenn du eine saubere, lineare Historie willst (besonders auf Feature-Branches). Deine lokalen Commits werden dann auf den geholten Commits neu abgespielt, statt einen Merge-Commit zu erzeugen. Nutze den normalen Pull (Merge), wenn du genau erhalten willst, wann welche Änderung gemacht wurde.
Ein Fast-Forward passiert, wenn dein lokaler Branch keine neuen Commits hat, die das Remote nicht hat. Git schiebt deinen Branch-Zeiger einfach bis zum Remote vor – ohne Merge-Commit. Hast du lokale Commits, muss Git entweder einen Merge-Commit erzeugen oder rebasen – und wenn du weder --rebase/--no-rebase angibst noch pull.rebase setzt, hält modernes Git mit „Need to specify how to reconcile divergent branches“ an.
Nutze git pull --rebase, um deine lokalen Commits auf den Remote-Commits neu abzuspielen – das ergibt eine lineare Historie. Oder nutze git pull --ff-only, das nur klappt, wenn ein Fast-Forward möglich ist (scheitert, wenn du lokale Commits voraus hast).
Kommt drauf an. Beim Pull per Merge lässt Git es zu, wenn die eingehenden Commits die von dir geänderten Dateien nicht berühren; sonst verweigert es mit „Your local changes ... would be overwritten by merge“. Mit --rebase blockiert jede nicht committete Änderung den Pull. Am besten: vorher committen oder git pull --rebase --autostash nutzen, das deine Änderungen automatisch stasht und wiederherstellt.
Git pausiert den Merge und markiert die Konfliktdateien. Öffne jede, suche die Konfliktmarker (<<<<<<<, =======, >>>>>>>), löse sie, dann git add auf die Datei und git commit, um den Merge abzuschließen. Mit git merge --abort brichst du ab (bei git pull --rebase: git rebase --continue / git rebase --abort).
Direkt nach dem Pull: git reset --hard ORIG_HEAD – Git sichert deine vorige Spitze bei Merges, Fast-Forwards und Rebases in ORIG_HEAD. Nutze nicht HEAD~1: Ein Fast-Forward kann mehrere Commits gebracht haben. --hard verwirft auch nicht committete Änderungen. Hat sich ORIG_HEAD seitdem bewegt, findest du die alte Spitze mit git reflog.
Meist pullst du vom falschen Branch oder Remote. Prüfe: git branch -vv für die Tracking-Infos, git remote -v für die Remotes, dann git fetch --all und git log origin/main, um die Remote-Commits zu sehen.
git pull origin main gibt Remote und Branch ausdrücklich an. git pull (ohne Argumente) nutzt den für deinen aktuellen Branch konfigurierten Tracking-Branch. Ist kein Tracking eingerichtet, bekommst du einen Fehler, der dich um die Angabe bittet.
Global: git config --global pull.rebase true (für Rebase) oder git config --global pull.rebase false (für Merge). Du kannst es auch pro Repository ohne --global setzen oder pro Branch mit git config branch.<name>.rebase true.