git pull
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 funktioniert "git revert"?
Der Befehl git pull führt zunächst den Befehl git fetch aus, der Inhalte von dem 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 Merge-Prozess besser zu veranschaulichen. Angenommen, wir haben ein Repository mit einem Haupt-Branch und einem Remote-Origin.
In diesem Szenario lädt git pull alle Änderungen ab dem Punkt herunter, an dem das lokale und das Haupt-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.
Zugehöriges Material
Git-Protokoll für Fortgeschrittene
Lösung anzeigen
Git kennenlernen mit Bitbucket Cloud
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 --rebase-Option 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. Die lokalen Commits E--F--G wurden umgeschrieben und werden nach den Remote-Commits im lokalen Origin/Main-Commit-Verlauf angezeigt.
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/＜aktueller-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 im Origin hinterlegten Version des Haupt-Branch Änderungen vorgenommen wurden, seit du das letzte Mal nachgeschaut hast. git merge integriert dann den Remote-Haupt-Branch sofort in den lokalen Haupt-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 --rebase-Option 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 dem --rebase-Flag 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 alwaysWenn 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 git pull ausgeführt und git merge initiiert.
Rebasing mit git pull anstatt Mergen
Im folgenden Beispiel zeigen wir dir, wie eine Synchronisierung mithilfe eines Rebase mit dem Haupt-Branch des zentralen Repositorys funktioniert:
git checkout main
git pull --rebase originHiermit werden deine lokale Änderungen den Beiträgen vorangestellt, die andere bereits geliefert haben.
Diesen Artikel teilen
Nächstes Thema
Lesenswert
Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.
Bitbucket-Blog
DevOps-Lernpfad
