Der git pull-Befehl wird verwendet, um Inhalte aus einem Remote-Repository herunterzuladen und unverzüglich das lokale Repository zu aktualisieren, damit die Inhalte übereinstimmen. In Git-basierten Workflows zur Zusammenarbeit ist es häufig erforderlich, Upstream-Änderungen mit deinem lokalen Repository zusammenzuführen. Der Befehl git pull ist eigentlich eine Kombination aus zwei anderen Befehlen: git fetch gefolgt von git merge. In der ersten Phase führt git pull einen git fetch aus, der den lokalen Branch umfasst, auf den HEAD verweist. Sobald die Inhalte heruntergeladen wurden, startet git pull einen Merge-Workflow. Es wird ein neuer Merge-Commit erstellt und HEAD wird so aktualisiert, dass er auf den neuen Commit verweist.

Verwendung von git pull

Wie es funktioniert

Der Befehl git pull führt zunächst git fetch aus, der Inhalte von einem angegebenen Remote-Repository herunterlädt. Dann wird ein git merge ausgeführt, um die Referenzen und Heads in einem neuen lokalen Merge-Commit zusammenzuführen. Sehen wir uns das folgende Beispiel an, um den Pull- und Zusammenführungsprozess besser zu veranschaulichen. Angenommen, wir haben ein Repository mit einem Master-Branch und einem Remote-Origin.

In diesem Szenario lädt git pull alle Änderungen ab dem Punkt herunter, an dem das lokale und das Master-Repository voneinander abweichen. In diesem Beispiel ist dies Punkt E. git pull ruft die abweichenden Remote-Commits A-B-C ab. Der Pull-Prozess erstellt dann einen neuen lokalen Merge-Commit, der die Inhalte der neuen abweichenden Remote-Commits enthält.

Im Diagramm oben sehen wir den neuen Commit H. Bei diesem Commit handelt es sich um einen neuen Merge-Commit, der die Inhalte der Remote-Commits A-B-C umfasst und über eine kombinierte Protokollnachricht verfügt. Dieses Beispiel ist eine von mehreren git pull-Merging-Strategien. Eine Option --rebase kann an git pull angefügt werden, um eine Rebase-Merging-Strategie anstatt eines Merge-Commit zu verwenden. Im nächsten Beispiel wird ein Rebase-Pull veranschaulicht. Angenommen, wir befinden uns an einem Ausgangspunkt unseres ersten Diagramms und wir haben git pull --rebase ausgeführt.

In diesem Diagramm sehen wir jetzt, dass ein Rebase-Pull nicht den neuen H-Commit erstellt. Stattdessen wurden beim Rebasing die Remote-Commits A--B--C kopiert und an den lokalen Origin/Master-Commit-Verlauf angehängt.

Allgemeine Optionen

git pull <remote>

Mit diesem Befehl rufst du die im angegebenen Repository hinterlegte Kopie des aktuellen Branches ab und führst diese Kopie sofort mit der lokalen Kopie zusammen. Er entspricht git fetch <remote> gefolgt von git merge origin/<current-branch>.

git pull --no-commit <remote>

Ähnlich wie beim Standard-Aufruf werden hier Remote-Inhalte abgerufen, aber es wird kein neuer Merge-Commit erstellt.

git pull --rebase <remote>

Dieser Befehl funktioniert ebenso wie der vorherige, verwendet statt git merge jedoch git rebase zur Integration des Remote-Branches in den lokalen Branch.

git pull --verbose

Liefert während eines Pulls ausführlichen Output, der die heruntergeladenen Inhalte und die Merge-Details anzeigt.

Erläuterung von Git Pull

git pull ist die Git-Version von svn update. Der Befehl ist eine einfache Möglichkeit, dein lokales Repository mit Upstream-Änderungen zu synchronisieren. Das nachfolgende Schaubild illustriert die einzelnen Schritte des Pull-Prozesses.

Zunächst scheint es, dass dein Repository synchronisiert ist. Doch dann offenbart git fetch, dass an der in "origin" hinterlegten Version des master Änderungen vorgenommen wurden, seit du das letzte Mal nachgeschaut hast. git merge integriert dann den Branch master des Remote-Repositorys sofort in den lokalen Branch.

Git pull und Synchronisation

git pull ist einer der vielen Befehle, die für das "Synchronisieren" von Remote-Inhalten verantwortlich sind. Mit dem Befehl git remote wird festgelegt, auf welchen Remote-Endpunkten die Synchronisierungsbefehle arbeiten. Der Befehl git push wird verwendet, um Inhalte in ein Remote-Repository hochzuladen.

Der Befehl git fetch kann mit git pull verwechselt werden. Beide werden verwendet, um Remote-Inhalte herunterzuladen. Es gibt einen wichtigen Sicherheitsunterschied zwischen git pull und git fetch. git fetch kann als "sichere" Option betrachtet werden, wohingegen git pull als unsicher angesehen werden kann. git fetch lädt die Remote-Inhalte herunter und verändert den Zustand des lokalen Repositorys nicht. Alternativ dazu lädt git pull Remote-Inhalte herunter und versucht sofort, den lokalen Zustand an die Inhalte anzupassen. Dies kann unabsichtlich dazu führen, dass sich das lokale Repository in einem Konfliktzustand befindet.

Pulling vs. Rebasing

Die Option --rebase kann verwendet werden, um einen linearen Verlauf durch Vermeidung unnötiger Merge-Commits sicherzustellen. Viele Entwickler ziehen das Rebasing dem Merging vor. Damit setzen sie ihre Änderungen quasi an die Spitze aller bisher vorgenommenen Änderungen durch andere. In diesem Sinne entspricht git pull mit der Option --rebase dem Befehl svn update noch viel eher als ein reiner git pull.

Tatsächlich sind Pulls mit --rebase ein so häufig genutzter Workflow, dass eine dedizierte Konfigurationsoption für sie implementiert wurde:

git config --global branch.autosetuprebase always

Wenn du diesen Befehl ausführst, nutzen zukünftige Befehle des Typs git pull statt git merge die Variante git rebase zur Integration.

Beispiele für Git Pull

Die folgenden Beispiele zeigen die Verwendung von git pull in gängigen Szenarien:

Standardverhalten

git pull

Das Ausführen des Standardaufrufs von git pull entspricht git fetch origin HEAD und git merge HEAD, wobei HEAD auf den aktuellen Branch verweist.

Git pull auf Remote-Ressourcen

git checkout new_feature
git pull <remote repo>

Im ersten Beispiel wird ein Checkout ausgeführt und zum Branch <newfeature> gewechselt. Danach wird der git pull ausgeführt und <remote repo> wird angefügt. Dadurch wird implizit der newfeature-Branch von <remote repo> abgerufen. Sobald der Download abgeschlossen ist, wird ein git merge initiiert.

Rebasing mit git pull anstatt Mergen

Im folgenden Beispiel zeigen wir dir, wie eine Synchronisierung mithilfe eines Rebase mit dem Master-Branch des zentralen Repositorys funktioniert:

git checkout master
git pull --rebase origin

Hiermit werden deine lokalen Änderungen den Beiträgen vorangestellt, die andere bereits geliefert haben.