Moderator Hinweis: Da diese Frage bereits 67 Antworten gepostet hat (einige von ihnen wurden gelöscht), sollten Sie überlegen, ob Sieetwas Neuesbeitragen einen anderen posten.
Was sind die Unterschiede zwischen git pull
und git fetch
?
In den einfachsten Ausdrücken führt git pull
einen git fetch
gefolgt von einem git merge
aus.
Sie können jederzeit einen git fetch
ausführen, um Ihre Fernverfolgungszweige unter refs/remotes/<remote>/
zu aktualisieren.
Diese Operation ändert niemals Ihre eigenen lokalen Niederlassungen unter refs/heads
und ist ohne Änderung Ihrer Arbeitskopie sicher. Ich habe sogar von Leuten gehört, die git fetch
regelmäßig in einem Cron-Job im Hintergrund laufen ließen (obwohl ich dies nicht empfehlen würde).
Ein git pull
ist das, was Sie tun würden, um eine lokale Zweigstelle mit ihrer Remote-Version auf den neuesten Stand zu bringen und gleichzeitig auch Ihre anderen Fernverfolgungszweige zu aktualisieren.
Git-Dokumentation: git pull
Wenn Sie pull
verwenden, versucht Git, Ihre Arbeit automatisch für Sie auszuführen. Es ist kontextsensitiv , also führt Git alle gezogenen Commits in den Zweig ein, in dem Sie gerade arbeiten. pull
fügt die Commits automatisch zusammen, ohne dass Sie sie zuerst überprüfen müssen . Wenn Sie Ihre Zweigstellen nicht genau verwalten, kann es zu häufigen Konflikten kommen.
Wenn Sie fetch
verwenden, sammelt Git alle Commits aus dem Zielzweig, die in Ihrem aktuellen Zweig nicht vorhanden sind, und speichert sie in Ihrem lokalen Repository . jedoch nicht mit Ihrem aktuellen Zweig verbunden . Dies ist besonders nützlich, wenn Sie Ihr Repository auf dem neuesten Stand halten müssen, aber an etwas arbeiten, das möglicherweise beschädigt wird, wenn Sie Ihre Dateien aktualisieren. Um die Commits in Ihren Master-Zweig zu integrieren, verwenden Sie merge
.
Es ist wichtig, die Designphilosophie von git der Philosophie eines traditionellen Quellcodeverwaltungswerkzeugs wie SVN gegenüberzustellen.
Subversion wurde mit einem Client/Server-Modell entworfen und erstellt. Es gibt ein einziges Repository, das den Server darstellt, und mehrere Clients können Code vom Server abrufen, darauf arbeiten und ihn anschließend wieder an den Server übergeben. Die Annahme ist, dass der Client immer den Server kontaktieren kann, wenn er eine Operation ausführen muss.
Git wurde entwickelt, um ein stärker verteiltes Modell zu unterstützen, ohne dass ein zentrales Repository erforderlich ist (wenn Sie möchten, können Sie auch eines verwenden). Git wurde so konzipiert, dass Client und Server nicht gleichzeitig online sein müssen. Git wurde so konzipiert, dass Personen mit einem unzuverlässigen Link sogar per E-Mail Code austauschen können. Es ist möglich, vollständig getrennt zu arbeiten und eine CD zu brennen, um den Code über git auszutauschen.
Um dieses Modell zu unterstützen, unterhält git ein lokales Repository mit Ihrem Code sowie ein zusätzliches lokales Repository, das den Status des Remote-Repositorys widerspiegelt. Durch das lokale Aufbewahren einer Kopie des Remote-Repositorys kann git die erforderlichen Änderungen selbst dann ermitteln, wenn das Remote-Repository nicht erreichbar ist. Wenn Sie die Änderungen später an eine andere Person senden müssen, kann git diese Änderungen zu einem Zeitpunkt übertragen, der dem Remote-Repository bekannt ist.
git fetch
ist der Befehl, der besagt "Bringen Sie meine lokale Kopie des Remote-Repositorys auf den neuesten Stand."
git pull
sagt "die Änderungen im Remote-Repository dahin bringen, wo ich meinen eigenen Code verwahre."
Normalerweise macht git pull
dies durch ein git fetch
, um die lokale Kopie des Remote-Repositorys auf den neuesten Stand zu bringen, und dann die Änderungen in Ihrem eigenen Code-Repository und möglicherweise in Ihrer Arbeitskopie zusammenzuführen.
Zum Mitnehmen ist zu beachten, dass sich auf Ihrer Workstation oft mindestens drei Kopien eines Projekts befinden. Eine Kopie ist Ihr eigenes Repository mit Ihrem eigenen Commit-Verlauf. Die zweite Kopie ist Ihre Arbeitskopie, in der Sie bearbeiten und erstellen. Die dritte Kopie ist Ihre lokale "zwischengespeicherte" Kopie eines Remote-Repositorys.
Hier ist Oliver Steeles Bild, wie alles zusammenpasst :
Wenn genügend Interesse besteht, könnte ich das Bild aktualisieren, um git clone
und git merge
... hinzuzufügen.
Ein Anwendungsfall von git fetch
ist, dass im Folgenden alle Änderungen in der Remote-Verzweigung seit dem letzten Pull-Vorgang angezeigt werden. Sie können also vor dem eigentlichen Pull-Vorgang prüfen, ob die Dateien in Ihrer aktuellen Zweig- und Arbeitskopie geändert werden könnten.
git fetch
git diff ...Origin
Es hat mich ein bisschen gekostet zu verstehen, was der Unterschied war, aber das ist eine einfache Erklärung. master
in Ihrem localhost ist ein Zweig.
Wenn Sie ein Repository klonen, rufen Sie das gesamte Repository an Ihren lokalen Host ab. Dies bedeutet, dass Sie zu diesem Zeitpunkt einen Origin/Master-Zeiger auf HEAD
haben und der Master auf dieselbe HEAD
zeigt.
wenn Sie anfangen zu arbeiten und Commits ausführen, bewegen Sie den Master-Zeiger auf HEAD
+ Ihre Commits. Der Origin/Master-Zeiger zeigt jedoch immer noch auf das, was beim Klonen war.
Der Unterschied wird also sein:
git fetch
ausführen, werden alle Änderungen im Remote-Repository ( GitHub ) abgerufen und der Origin/master-Zeiger auf HEAD
verschoben. In der Zwischenzeit wird Ihr lokaler Zweigmeister weiterhin auf den aktuellen Standort zeigen.git pull
ausführen, ruft dieser grundsätzlich (wie zuvor erläutert) ab und führt alle neuen Änderungen in Ihrem Hauptzweig zusammen und bewegt den Zeiger auf HEAD
.Kurz
git fetch
ähnelt pull
, führt jedoch keine Zusammenführung durch. Das heißt, es werden Remote-Updates abgerufen (refs
und objects
), Ihr lokaler Server bleibt jedoch gleich (d. h. Origin/master
wird aktualisiert, master
bleibt jedoch unverändert).
git pull
wird von einer Fernbedienung heruntergezogen und sofort zusammengeführt.
Mehr
git clone
klont ein Repo.
git rebase
speichert Dinge aus Ihrem aktuellen Zweig, die sich nicht im Upstream-Zweig befinden, in einem temporären Bereich. Ihr Zweig ist jetzt derselbe wie vor Beginn Ihrer Änderungen. So wird git pull -rebase
die Remote-Änderungen herunterziehen, Ihren lokalen Zweig zurückspulen und Ihre Änderungen über Ihrem aktuellen Zweig nacheinander wiedergeben, bis Sie auf dem neuesten Stand sind.
git branch -a
zeigt Ihnen auch genau, was in allen Ihren Filialen vor Ort und in der Ferne vor sich geht.
Dieser Blogeintrag war nützlich:
Der Unterschied zwischen Git Pull, Git Fetch und Git-Klon (und Git Rebase) - Mike Pearce
und deckt git pull
, git fetch
, git clone
und git rebase
ab.
====
AKTUALISIEREN
Ich dachte, ich würde dies aktualisieren, um zu zeigen, wie Sie dies in der Praxis tatsächlich verwenden würden.
Aktualisieren Sie Ihr lokales Repo von der Fernbedienung aus (aber führen Sie keine Zusammenführung durch):
git fetch
Nachdem Sie die Updates heruntergeladen haben, sehen Sie die Unterschiede:
git diff master Origin/master
Wenn Sie mit diesen Updates zufrieden sind, führen Sie Folgendes zusammen:
git pull
Anmerkungen:
Zu Schritt 2: Weitere Informationen zu Unterschieden zwischen lokalen und Remotes finden Sie unter: Wie vergleicht man einen lokalen Git-Zweig mit seinem entfernten Zweig?
Zu Schritt 3: Es ist wahrscheinlich genauer (z. B. bei einem sich schnell ändernden Repo), hier einen git rebase Origin
auszuführen. Siehe @Justin Ohms Kommentar in einer anderen Antwort.
Siehe auch: http://longair.net/blog/2009/04/16/git-fetch-and-merge/
git-pull - Abrufen und Zusammenführen mit einem anderen Repository oder einem lokalen Zweig SYNOPSIS git pull… DESCRIPTION Führt git-fetch mit den angegebenen Parametern aus. und ruft git-merge auf, um den/die abgerufenen Köpfe mit dem aktuellen Zweig zusammenzuführen. Ruft mit --rebase git-rebase Anstelle von git-merge . .__ auf. Beachten Sie, dass Sie verwenden können. (aktuelles Verzeichnis) als <Repository> zum Abrufen von aus dem lokalen Repository - Dies ist nützlich, wenn lokale Zweige in den aktuellen Zweig verzweigt werden sollen. Beachten Sie außerdem, dass Optionen für git-pull selbst gedacht sind und zugrunde liegende git-merge muss vor den für git-fetch ..__ angegebenen Optionen angegeben werden.
Sie würden ziehen, wenn Sie möchten, dass die Historien zusammengeführt werden. Sie würden abrufen, wenn Sie nur "die Codez wollen", da eine Person hier einige Artikel markiert hat.
Sie können aus einem Remote-Repository abrufen, die Unterschiede anzeigen und dann ziehen oder zusammenführen.
Dies ist ein Beispiel für ein entferntes Repository mit dem Namen Origin
und einen Zweig mit dem Namen master
, der den entfernten Zweig verfolgt Origin/master
:
git checkout master
git fetch
git diff Origin/master
git rebase Origin master
Die kurze und einfache Antwort lautet, dass git pull
einfach git fetch
gefolgt von git merge
ist.
Es ist sehr wichtig anzumerken, dass git pull
automatisch zusammengeführt wird, ob es Ihnen gefällt oder nicht. Dies kann natürlich zu Mischkonflikten führen. Nehmen wir an, Ihre Fernbedienung ist Origin
und Ihr Zweig ist master
. Wenn Sie git diff Origin/master
vor dem Abrufen ziehen, sollten Sie eine Vorstellung von möglichen Zusammenführungskonflikten haben und Ihre lokale Niederlassung entsprechend vorbereiten.
Neben dem Ziehen und Schieben enthalten auch einige Workflowsgit rebase
, wie diesen, den ich aus dem verlinkten Artikel umschreibe:
git pull Origin master
git checkout foo-branch
git rebase master
git Push Origin foo-branch
Wenn Sie sich in einer solchen Situation befinden, könnten Sie versucht sein, git pull --rebase
. Wenn Sie nicht wirklich wissen, was Sie tun, würde ich davon abraten. Diese Warnung stammt von der Seite man
für git-pull
, Version 2.3.5
:
Dies ist eine potenziell gefährliche Betriebsart. Es schreibt neu Geschichte, die nicht gut ist, wenn Sie diese Geschichte veröffentlicht haben bereits. Verwenden Sie diese Option nur, wenn Sie git-rebase (1) .__ gelesen haben. vorsichtig.
OK, hier sind einige Informationen zu git pull
und git fetch
, damit Sie die tatsächlichen Unterschiede verstehen können. In wenigen einfachen Worten erhält fetch die neuesten Daten, aber der Code ändert sich nicht mit dem aktuellen lokalen Zweigcode verwechseln, aber pull ruft die Codeänderungen ab und führt sie mit Ihrem lokalen Zweig zusammen. Lesen Sie weiter, um weitere Informationen zu erhalten:
Es werden alle refs und objects und alle neuen Verzweigungen in Ihr lokales Repository heruntergeladen ...
Holt Zweige und/oder Tags (zusammen "refs") von einem oder mehreren andere Repositorys zusammen mit den Objekten, die zur Vervollständigung ihres Geschichten. Fernverfolgungszweige werden aktualisiert (Informationen zur Steuerung dieses Verhaltens finden Sie in der folgenden Beschreibung ).
Standardmäßig ist jedes Tag, das auf die abgerufenen Historien verweist, auch geholt; Der Effekt ist, Tags zu holen, die auf Zweige zeigen, die Sie sind interessiert. Dieses Standardverhalten kann mit .__ geändert werden. die Optionen --tags oder --no-tags oder durch Konfigurieren von remote..tagOpt. Durch die Verwendung einer refspec, die Tags explizit abruft, Sie können Tags abrufen, die nicht in interessierte Zweige zeigen auch in.
git fetch kann entweder von einem einzelnen benannten Repository oder von einer URL oder von .__ abrufen. aus mehreren Repositories gleichzeitig, wenn angegeben ist und es ein Fernbedienungen Eintrag in der Konfigurationsdatei. (Siehe git-config 1 ).
Wenn keine Remote angegeben ist, ist die Origin-Fernbedienung standardmäßig verwendet, es sei denn, es ist ein Upstream-Zweig für den aktuellen .__ konfiguriert. Ast.
Die Namen der abgerufenen Referenzen, zusammen mit den Objektnamen Sie zeigen auf, werden in .git/FETCH_HEAD geschrieben. Diese Informationen können .__ sein. Wird von Skripten oder anderen git-Befehlen wie git-pull verwendet.
Die Änderungen von remote werden auf den aktuellen Zweig in local ... angewendet.
Enthält Änderungen aus einem Remote-Repository in den aktuellen Zweig. Im Standardmodus ist git pull die Abkürzung für git fetch gefolgt von git merge FETCH_HEAD.
Genauer gesagt, git pull führt git fetch mit den angegebenen Parametern und ruft git merge auf, um die abgerufenen Zweigköpfe mit dem aktuellen .__ zusammenzuführen. Ast. Mit --rebase wird git rebase statt git merge ausgeführt.
sollte der Name eines Remote-Repositorys sein, das an .__ übergeben wird. git-fetch 1 . kann eine beliebige entfernte Referenz (zum Beispiel den Namen eines Tags) oder sogar eine Sammlung von Refs mit entsprechenden .__ benennen. Fernverfolgungszweige (z. B. refs/heads/: refs/remote/Origin /), In der Regel ist dies jedoch der Name einer Verzweigung im Remote-Repository.
Standardwerte für und werden aus der .__ gelesen. "remote" - und "merge" -Konfiguration für den aktuellen Zweig, wie durch .__ festgelegt. Git-Zweig - Spur.
Ich erstelle das visual unten, um Ihnen zu zeigen, wie git fetch
und git pull
zusammenarbeiten ...
Diese interaktive grafische Darstellung ist sehr hilfreich beim Verständnis von git: http://ndpsoftware.com/git-cheatsheet.html
git fetch
"lädt" nur die Änderungen von der entfernten in Ihr lokales Repository herunter. git pull
lädt die Änderungen herunter und führt sie in Ihren aktuellen Zweig ein. "Im Standardmodus ist git pull
die Abkürzung für git fetch
, gefolgt von git merge FETCH_HEAD
."
Wenn ich in den obigen Antworten von Pull & Fetch spreche, möchte ich einen interessanten Trick teilen:
git pull --rebase
Dieser Befehl ist der nützlichste Befehl in meinem Git-Leben, der viel Zeit gespart hat.
Bevor Sie Ihre neuen Commits an den Server senden, probieren Sie diesen Befehl aus, um die neuesten Serveränderungen (mit Abruf + Zusammenführen) automatisch zu synchronisieren und Ihr Commit ganz oben in git log zu setzen. Sie müssen sich keine Gedanken über manuelles Ziehen/Zusammenführen machen.
Details finden Sie unter: http://gitolite.com/git-pull--rebase
Ich möchte eine visuelle Darstellung der Situation haben, um diese Dinge zu erfassen. Vielleicht würden andere Entwickler es auch gerne sehen, daher hier meine Ergänzung. Ich bin mir nicht ganz sicher, ob alles stimmt, also bitte kommentieren, wenn Sie Fehler finden.
LOCAL SYSTEM
. =====================================================
================= . ================= =================== =============
REMOTE REPOSITORY . REMOTE REPOSITORY LOCAL REPOSITORY WORKING COPY
(Origin) . (CACHED)
for example, . mirror of the
a github repo. . remote repo
Can also be .
multiple repo's .
.
.
FETCH *------------------>*
Your local cache of the remote is updated with the Origin (or multiple
external sources, that is git's distributed nature)
.
PULL *-------------------------------------------------------->*
changes are merged directly into your local copy. when conflicts occur,
you are asked for decisions.
.
COMMIT . *<---------------*
When coming from, for example, Subversion, you might think that a commit
will update the Origin. In git, a commit is only done to your local repo.
.
Push *<---------------------------------------*
Synchronizes your changes back into the Origin.
Einige wichtige Vorteile für einen abgerufenen Spiegel der Fernbedienung sind:
Ich habe auch damit zu kämpfen. Tatsächlich bin ich mit einer Google-Suche genau derselben Frage hierher gekommen. Nachdem ich all diese Antworten gelesen hatte, zeichnete ich schließlich ein Bild in meinem Kopf und ich beschloss, dies auf den Stand der 2 Repositories und 1 Sandbox sowie der im Laufe der Zeit ausgeführten Aktionen zu überprüfen, während ich die Version davon beobachtete. Also hier ist was ich mir ausgedacht habe. Bitte korrigieren Sie mich, wenn ich irgendwo versaut habe.
Die drei Repos mit einem Abruf:
--------------------- ----------------------- -----------------------
- Remote Repo - - Remote Repo - - Remote Repo -
- - - gets pushed - - -
- @ R01 - - @ R02 - - @ R02 -
--------------------- ----------------------- -----------------------
--------------------- ----------------------- -----------------------
- Local Repo - - Local Repo - - Local Repo -
- pull - - - - fetch -
- @ R01 - - @ R01 - - @ R02 -
--------------------- ----------------------- -----------------------
--------------------- ----------------------- -----------------------
- Local Sandbox - - Local Sandbox - - Local Sandbox -
- Checkout - - new work done - - -
- @ R01 - - @ R01+ - - @R01+ -
--------------------- ----------------------- -----------------------
Die drei Repos mit einem Zug
--------------------- ----------------------- -----------------------
- Remote Repo - - Remote Repo - - Remote Repo -
- - - gets pushed - - -
- @ R01 - - @ R02 - - @ R02 -
--------------------- ----------------------- -----------------------
--------------------- ----------------------- -----------------------
- Local Repo - - Local Repo - - Local Repo -
- pull - - - - pull -
- @ R01 - - @ R01 - - @ R02 -
--------------------- ----------------------- -----------------------
--------------------- ----------------------- -----------------------
- Local Sandbox - - Local Sandbox - - Local Sandbox -
- Checkout - - new work done - - merged with R02 -
- @ R01 - - @ R01+ - - @R02+ -
--------------------- ----------------------- -----------------------
Dies half mir zu verstehen, warum ein Abruf so wichtig ist.
Der Unterschied zwischen GIT Fetch und GIT Pull kann mit folgendem Szenario erklärt werden: (Wenn Sie sich daran erinnern, dass Bilder mehr sprechen als Worte! Ich habe eine bildliche Darstellung bereitgestellt)
Nehmen wir ein Beispiel, dass Sie mit Ihren Teammitgliedern an einem Projekt arbeiten. Sie werden also ein Hauptzweig des Projekts sein, und alle Mitwirkenden müssen es in ihr eigenes lokales Repository einordnen und dann an diesem lokalen Zweig arbeiten, um Module zu ändern/hinzufügen, dann zum Hauptzweig zurückkehren.
Anfangsstatus der beiden Zweige, wenn Sie das Hauptprojekt in Ihrem lokalen Repository aufgespalten haben, wird wie folgt aussehen (A
, B
und C
sind bereits abgeschlossene Module des Projekts).
Nun haben Sie mit der Arbeit an dem neuen Modul begonnen (angenommen, D
) und wenn Sie das D
-Modul abgeschlossen haben, das Sie zum Hauptzweig verschieben möchten. In der Zwischenzeit hat einer Ihrer Teamkollegen das neue Modul E
, F
und entwickelt C
geändert.
Was nun passiert ist, ist, dass Ihr lokales Repository hinter dem ursprünglichen Fortschritt des Projekts fehlt. Wenn Sie also Ihre Änderungen in den Hauptzweig verschieben, kann dies zu Konflikten führen und zu einer Fehlfunktion Ihres Moduls D
führen.
Um solche Probleme zu vermeiden und parallel zum ursprünglichen Projektfortschritt zu arbeiten, gibt es zwei Möglichkeiten:
1. Git Fetch- Hiermit werden alle Änderungen heruntergeladen, die am Origin/Hauptzweigprojekt vorgenommen wurden und nicht in Ihrem lokalen Zweig vorhanden sind. Und wartet, bis der Befehl "Git Merge" die Änderungen übernommen hat, die in Ihrem Repository oder Zweig abgerufen wurden.
Jetzt können Sie die Dateien sorgfältig überwachen, bevor Sie sie mit Ihrem Repository zusammenführen. Sie können auch D
ändern, falls dies aufgrund von Modified C
erforderlich ist.
2. Git Pull- Dadurch wird Ihr lokaler Zweig mit dem Origin/Haupt-Zweig aktualisiert. Das heißt, es wird eine Kombination aus Git Fetch und Git nacheinander zusammengefügtDies kann jedoch dazu führen, dass Konflikte auftreten Es wird daher empfohlen, Git Pull mit einer sauberen Kopie zu verwenden.
Wir sagen einfach:
git pull == git fetch + git merge
Wenn Sie git pull
ausführen, müssen Sie die Daten nicht mit local zusammenführen. Wenn Sie git fetch
ausführen, müssen Sie git merge
ausführen, um den neuesten Code auf Ihrem lokalen Computer zu erhalten. Andernfalls würde der lokale Maschinencode nicht ohne Zusammenführen geändert.
Wenn Sie also in Git Gui holen, müssen Sie die Daten zusammenführen. Abrufen selbst führt die Codeänderungen nicht an Ihrem lokalen Computer durch. Sie können dies überprüfen, wenn Sie den Code aktualisieren, indem Sie Einmal abrufen und abrufen; Der Code ändert sich nicht. Dann mischen Sie zusammen ... Sie sehen den geänderten Code.
git fetch
ruft den Code vom Remote-Server auf Ihre Nachverfolgungszweige in Ihrem lokalen Repository herunter. Wenn Ihre Fernbedienung Origin
(Standardeinstellung) lautet, befinden sich diese Verzweigungen innerhalb von Origin/
, beispielsweise Origin/master
, Origin/mybranch-123
usw. Dies sind keine aktuellen Verzweigungen, sondern local - Kopien dieser Verzweigungen vom Server.
git pull
führt einen git fetch
aus, fügt dann auch den Code aus dem Tracking-Zweig in Ihre aktuelle lokale Version dieses Zweigs ein. Wenn Sie für diese Änderungen noch nicht bereit sind, git fetch
zuerst.
git fetch
ruft entfernte Zweige ab, sodass Sie sie mit dem aktuellen Zweig git diff
oder git merge
abrufen können. git pull
wird auf dem entfernten Zweig ausgeführt, der vom aktuellen Zweig verfolgt wird, und das Ergebnis wird dann zusammengeführt. Sie können git fetch
verwenden, um zu prüfen, ob Aktualisierungen für den Remote-Zweig vorhanden sind, ohne dass diese mit Ihrem lokalen Zweig verbunden werden müssen.
Git Fetch
Sie laden Änderungen von Origin über Abruf in Ihre lokale Zweigstelle herunter. Fetch fragt das Remote-Repo nach allen Commits, die andere gemacht haben, jedoch nicht in Ihrem lokalen Repo. Fetch lädt diese Commits herunter und fügt sie dem lokalen Repository hinzu.
Git Merge
Sie können Änderungen, die Sie mit Fetch heruntergeladen haben, mit dem Befehl merge anwenden. Merge nimmt die von fetch abgerufenen Commits und versucht, sie Ihrem lokalen Zweig hinzuzufügen. Die Zusammenführung behält den Commit-Verlauf Ihrer lokalen Änderungen bei, sodass Git wissen kann, wie andere Ihre Änderungen zusammenführen können, wenn Sie Ihren Zweig mit Push gemeinsam nutzen.
Git Pull
Abrufen und Zusammenführen laufen oft genug zusammen, sodass ein Befehl erstellt wurde, der die beiden Pull-Befehle kombiniert. Pull führt einen Abruf und dann eine Zusammenführung aus, um die heruntergeladenen Commits in Ihrem lokalen Zweig hinzuzufügen.
Der einzige Unterschied zwischen git pull
und git fetch
ist folgender:
git pull
zieht aus einem entfernten Zweig und fügt ihn zusammen.
git fetch
ruft nur den entfernten Zweig ab, führt jedoch keine Zusammenführung durch
git pull = git fetch + git merge ...
Git erlaubt, dass chronologisch ältere Commits nach neueren Commits angewendet werden. Aus diesem Grund ist das Übertragen von Commits zwischen Repositorys in zwei Schritte unterteilt:
Kopieren neuer Commits aus dem Remote-Zweig in die Kopie dieses Remote-Zweigs innerhalb des lokalen Repos.
(Repo-zu-Repo-Vorgang) [email protected] >> remote/Origin/[email protected]
Neue Commits in die lokale Niederlassung integrieren
(Inside-Repo-Vorgang) remote/Origin/[email protected] >> [email protected]
Es gibt zwei Möglichkeiten, Schritt 2 auszuführen. Sie können:
In git
-Terminologie ist Schritt 1 git fetch
, Schritt 2 ist git merge
oder git rebase
git pull
ist git fetch
und git merge
Was ist der Unterschied zwischen
git pull
undgit fetch
?
Um dies zu verstehen, müssen Sie zunächst verstehen, dass Ihr lokales git nicht nur Ihr lokales Repository verwaltet, sondern auch eine lokale Kopie des Remote-Repositorys.
git fetch
bringt Ihre lokale Kopie des Remote-Repositorys auf den neuesten Stand. Wenn Ihr Remote-Repository beispielsweise GitHub ist, möchten Sie möglicherweise alle Änderungen, die im Remote-Repository vorgenommen wurden, in Ihre lokale Kopie des Remote-Repositorys holen. Dadurch können Sie Vorgänge wie Vergleichen oder Zusammenführen ausführen.
git pull
hingegen bringt die Änderungen im Remote-Repository in den Bereich, in dem Sie Ihren eigenen Code aufbewahren. Normalerweise führt git pull
zuerst einen git fetch
aus, um die lokale Kopie des Remote-Repositorys auf den neuesten Stand zu bringen, und führt dann die Änderungen in Ihr eigenes Code-Repository und möglicherweise in Ihre Arbeitskopie ein.
Git erhält den Zweig der neuesten Version mit zwei Befehlen vom Remote zum Local:
git fetch: Git wird die neueste Version von Remote zu Local bringen, aber nicht automatisch zusammenführen . git fetch Origin master
git log -p master..Origin/master
git merge Origin/master
Die obigen Befehle bedeuten, dass die neueste Version des Hauptzweigs von Origin aus dem Remote-Zweig in den Origin-Zweig heruntergeladen wird. Und vergleicht dann den lokalen Master-Zweig und den Origin-Master-Zweig. Schließlich verschmelzen.
git pull: Git wird die neueste Version von der Fernbedienung holen und mit der lokalen Version zusammenführen.
git pull Origin master
Der obige Befehl entspricht git fetch
und git merge
. In der Praxis ist git fetch
vielleicht sicherer, da wir vor dem Zusammenführen die Änderungen sehen und entscheiden können, ob das Zusammenführen erfolgt.
git pull == (git holen + git zusammenführen)
git fetch ändert sich nicht in lokale Zweige.
Wenn Sie bereits über ein lokales Repository mit einer Remote-Einrichtung für das gewünschte Projekt verfügen, können Sie mithilfe von git fetch alle Verzweigungen und Tags für die vorhandene Remote-Datenbank abrufen. ... Fetch nimmt keine Änderungen an lokalen Verzweigungen vor. Sie müssen also einen entfernten Zweig mit einem gepaarten lokalen Zweig zusammenführen, um die neuen Abrufänderungen zu übernehmen. von github
Tatsächlich verwaltet Git eine Kopie Ihres eigenen Codes und Des Remote-Repositorys.
Mit dem Befehl git fetch
wird Ihre lokale Kopie auf den neuesten Stand gebracht, indem Daten aus dem Remote-Repository abgerufen werden. Der Grund, warum wir dies brauchen, ist, dass jemand anderes den Code geändert hat und Sie sich auf dem Laufenden halten möchten.
Der Befehl git pull
bringt die Änderungen im Remote-Repository dahin, wo Sie Ihren eigenen Code aufbewahren. Normalerweise macht git pull
dies, indem zuerst ein 'git-Abruf' ausgeführt wird, um die lokale Kopie des Remote-Repositorys auf den neuesten Stand zu bringen. Anschließend werden die Änderungen in Ihr eigenes Code-Repository und möglicherweise in Ihre Arbeitskopie eingefügt.
Versuchen, klar und einfach zu sein.
Der Befehl git pull ist tatsächlich eine shortcut
für git fetch, gefolgt von dem Befehl git merge oder git rebase, je nach Konfiguration. Sie können Ihr Git-Repository so konfigurieren, dass git pull ein Abruf ist, gefolgt von einer Rebase.
Eine einfache grafische Darstellung für Anfänger
hier,
git pull
holt Code aus dem Repository und rebase mit deinem lokalen ... in git pull können neue Commits erstellt werden.
aber in ,
git holen
holt Code aus dem Repository und wir müssen ihn mit git rebase
manuell neu abstützen
zB: Ich werde vom Server-Master abholen und ihn in meinem lokalen Master wiederherstellen.
1) git pull (rebase erfolgt automatisch):
git pull Origin master
hier ist Origin Ihr Remote-Repo. Master ist Ihr Zweig
2) git fetch (manuell neu abstimmen müssen):
git fetch Origin master
server-Änderungen werden von Origin abgerufen. und es wird in Ihrem lokalen sein, bis Sie es von sich aus rebasieren. Wir müssen Konflikte manuell beheben, indem Codes überprüft werden.
git rebase Origin/master
dadurch wird der Code in local umgewandelt. Bevor Sie sicherstellen, dass Sie in der richtigen Branche sind.
git pull = git fetch + git merge
Von Pro Git § 2.5 Git-Grundlagen - Arbeiten mit Fernbedienungen: Abrufen und Ziehen von Fernbedienungen :
Es ist wichtig zu beachten, dass der Befehl
fetch
die Daten in Ihr lokales Repository zieht - es ist jedoch nicht mischen Sie es automatisch mit einer Ihrer Arbeiten zusammen oder ändern Sie das, was Sie sind. derzeit arbeitet an. Sie müssen es manuell in Ihre Arbeit einbinden wenn du bereit bist.Wenn Sie einen Zweig eingerichtet haben, um einen entfernten Zweig zu verfolgen, können Sie die .__ verwenden.
git pull
Befehl zum automatischen Abrufen und anschließenden Zusammenführen eines Remote-Objekts verzweige in deine jetzige Niederlassung. Dies kann einfacher oder mehr sein komfortabler Workflow für Sie; und standardmäßig der Befehlgit clone
Richtet Ihren lokalen Master-Zweig automatisch ein, um die entfernte .__ zu verfolgen. Master-Zweig auf dem Server, von dem Sie geklont haben (vorausgesetzt, die Remote-Station hat einen Master-Zweig). Das Ausführen vongit pull
ruft im Allgemeinen Daten aus der .__ ab. Server, von dem Sie ursprünglich geklont haben, und versucht automatisch, ihn zusammenzuführen in den Code, an dem Sie gerade arbeiten.
git pull
Es führt zwei Funktionen mit einem einzigen Befehl aus.
Es ruft alle Änderungen ab, die am entfernten Zweig vorgenommen wurden, und führt diese Änderungen dann in Ihren lokalen Zweig ein. Sie können das Verhalten von pull auch ändern, indem Sie --rebase übergeben. Der Unterschied zwischen Merge und Rebase kann gelesen werden hier
git holen
Git-Abruf erledigt nur die Hälfte der Arbeit von Git-Pull. Es bringt nur die Remote-Änderungen in Ihr lokales Repo, aber wendet sie nicht auf Ihre Niederlassungen an. Sie müssen diese Änderungen explizit anwenden. Dies kann wie folgt durchgeführt werden:
git fetch
git rebase Origin/master
Man muss die Natur des Idioten berücksichtigen. Sie haben Fernbedienungen und Ihre lokalen Niederlassungen (nicht unbedingt die gleichen). Im Vergleich zu anderen Versionskontrollsystemen kann dies etwas verwirrend sein.
Normalerweise wird beim Auschecken einer Fernbedienung eine lokale Kopie erstellt, die die Fernbedienung verfolgt.
git fetch arbeitet mit dem entfernten Zweig zusammen und aktualisiert Ihre Informationen.
Es ist tatsächlich der Fall, wenn andere SWEs in derselben Branche arbeiten, und selten in kleinen Dev-One-Filialen.
Ihre Arbeit in der lokalen Niederlassung ist noch intakt. Um die Änderungen in Ihren lokalen Zweig zu übernehmen, müssen Sie die Änderungen aus dem entfernten Zweig zusammenführen/neu stufen.
git pull führt genau diese beiden Schritte aus (d. h. --rebase statt reihen)
Wenn Ihr lokaler Verlauf und der entfernte Verlauf Konflikte aufweisen, werden Sie während eines git Push zum Zusammenführen der Änderungen gezwungen, um Ihre Änderungen zu veröffentlichen.
Daher hängt es wirklich von der Art Ihrer Arbeitsumgebung und der Erfahrung ab, was Sie verwenden sollen.
Von git Spickzettel :
git fetch <remote> // Download all changes from <remote>, but don't integrate into HEAD
git pull <remote> <branch> // Download changes and directly merge/integrate into HEAD
Von dem, was ich verstanden habe,
Git pull - Zieht von einer angegebenen Fernbedienung (vom Benutzer festgelegt) herunter und fügt sie sofort in einem Zweig zusammen, in dem wir uns gerade befinden. Es ist im Grunde eine Mischung aus Befehlen zum Abrufen und Zusammenführen.
Git Fetch - Es ist dasselbe wie Pull, aber es wird keine Zusammenführung vorgenommen. So können Sie die Dateien sorgfältig überwachen, bevor Sie sie zusammenführen.
Diese URL muss für das weitere Verständnis hilfreich sein: Der Unterschied zwischen Git Pull, Git Fetch und Git Clone (und Git Rebase).
Kurz und einfach ausgedrückt:
git fetch
: Schau nach, ob es Neues gibt.
git pull
: Nimm die neuen Sachen und lege sie auf deine Sachen.
Ich glaube, die meisten Antworten haben den Unterschied gut beantwortet. Ich möchte betonen, wann stattdessen welche verwendet wird.
Fetch kann nützlich sein, wenn Sie das Update von anderen Entwicklern benötigen und trotzdem Ihre Arbeit unbeeinträchtigt fortsetzen möchten. Personen, die häufig offline arbeiten und arbeiten möchten, verwenden fetch
, um das neueste Update zu erhalten, bis sie online ist. Später, wenn sie mit ihren Änderungen vertraut ist, fügt sie die aus dem Zweig in ihren Arbeitsbereich ein.
Menschen, die online arbeiten und sich ihrer Änderungen sehr sicher sind und den neuesten Code und merge
erhalten möchten, verwenden pull
. Ich verwende selten fetch
, um die neuesten Updates zu überprüfen, überprüfe ich sie über die GitHub-Website und arbeite immer offline. Wie ich bereits erwähnt habe, könnten Sie das obige Szenario verwenden.
Git Fetch
Hilft Ihnen, über die neuesten Updates von einem git repository
informiert zu werden. Angenommen, Sie arbeiten in einem Team, das GitFlow
verwendet, wobei das Team an mehreren branches
(Funktionen) arbeitet. Mit git fetch --all
command
können Sie sich über alle neuen branches
in repository
informieren.
Meist wird git fetch
mit git reset
verwendet. Sie möchten beispielsweise alle Ihre lokalen Änderungen auf den aktuellen Repository-Status zurücksetzen.
git fetch --all // get known about latest updates
git reset --hard Origin/[branch] // revert to current branch state
Git pull
Dieser Befehl aktualisiert Ihren branch
mit dem aktuellen repository
branch
-Status. Fahren wir mit GitFlow
fort. Mehrere Funktionen branches
waren merged
und develop
. Wenn Sie neue Funktionen für das Projekt entwickeln möchten, müssen Sie zur Entwicklung branch
gehen und einen git pull
ausführen, um den aktuellen Status von develop
branch
abzurufen.
Dokumentation für GitFlow https://Gist.github.com/peterdeweese/4251497
Git-Abruf synchronisiert den Katalog des Remote-Repositorys mit Ihrem lokalen. Die Datei-/Code-Änderungen von Remote zu Ihrem lokalen Zweig werden nicht zusammengeführt.
Git pull lädt die Änderungen in Bezug auf Ihren aktuellen lokalen Zweig herunter und führt sie dann zusammen.
Von diesem tollen Attlassian Tutorial:
Der Befehl git fetch
lädt Commits, Dateien und Refs aus einem Remote-Repository in Ihr lokales Repo herunter.
Abrufen ist das, was Sie tun, wenn Sie sehen möchten, woran alle else gearbeitet haben. Es ähnelt svn update insofern, als Sie sehen, wie die zentrale Historie fortgeschritten ist, aber Sie müssen die Änderungen nicht tatsächlich in Ihrem Repository zusammenführen. Git isoliert den abgerufenen Inhalt als vorhandenen lokalen Inhalt, er hat absolut keine Auswirkung auf Ihre lokale Entwicklungsarbeit. Abgerufener Inhalt muss explizit mit dem Befehl git checkout
ausgecheckt werden. Dadurch wird das Abrufen eine sichere Möglichkeit, Commits zu überprüfen, bevor sie in Ihr lokales Repository integriert werden.
Beim Herunterladen von Inhalten aus einem Remote-Repo stehen die Befehle git pull
und git fetch
zur Verfügung, um die Aufgabe auszuführen. Sie können git fetch
als "sichere" Version der beiden Befehle betrachten. Der Remote-Inhalt wird heruntergeladen, der Arbeitsstatus Ihres lokalen Repos wird jedoch nicht aktualisiert, und Ihre aktuelle Arbeit bleibt erhalten. git pull
ist die aggressivere Alternative. Es wird den Remote-Inhalt für den aktiven lokalen Zweig heruntergeladen und sofort git merge
ausgeführt, um ein Zusammenführungs-Commit für den neuen Remote-Inhalt zu erstellen. Wenn ausstehende Änderungen in Bearbeitung sind, führt dies zu Konflikten und einem Anstoß für die Lösung des Zusammenführungskonflikts.
Mit git pull
:
git merge
tut.git fetch
, wo nur Ihr .git/refs/remotes
wirkt, wirkt sich git pull sowohl auf .git/refs/remotes
und.git/refs/heads/
aus.git fetch
aktualisiere, wo mache ich dann Änderungen? Wo speichert git fetch die neuen Commits?Tolle Frage. Es legt es irgendwo getrennt von Ihrer Arbeitskopie ab. Aber wieder wo? Lass es uns herausfinden.
Führen Sie in Ihrem Projektverzeichnis (dh wo Sie Ihre git
-Befehle ausführen) Folgendes aus:
ls
. Dadurch werden die Dateien und Verzeichnisse angezeigt. Nichts cooles, ich weiß.
Jetzt ls -a
. Dies zeigt dot files ie Dateien, die mit .
beginnen. Sie können dann ein Verzeichnis mit dem Namen: .git
sehen.
cd .git
. Dies wird natürlich Ihr Verzeichnis ändern. ls
. Sie sehen eine Liste von Verzeichnissen. Wir suchen nach refs
. cd refs
.heads
und remotes
. Verwenden Sie cd
, um auch in ihnen nachzuschauen. git fetch
, den Sie tun, aktualisiert Elemente im /.git/refs/remotes
-Verzeichnis. Es wird nichts im Verzeichnis /.git/refs/heads
aktualisiert.git pull
führt zuerst den git fetch
aus, aktualisiert Elemente im /.git/refs/remotes
-Verzeichnis, führt dann eine Zusammenführung mit dem lokalen Code durch und ändert dann den Kopf im /.git/refs/heads
-Verzeichnis. Eine sehr gute verwandte Antwort kann auch gefunden werden Wo platziert sich 'git fetch'?
Suchen Sie auch nach "Schrägstrichnotation" in Git-Benennungskonventionen post.
Wie die meisten zweifellos geantwortet haben, ist git-fetch plus merge. Ich möchte darauf hinweisen, dass:
wenn Sie vor dem Zusammenführen prüfen möchten, sollten Sie git-fetch gefolgt von git-pull verwenden.
Bei cronjob
ist es hilfreich, dies wie im folgenden Skript gezeigt zu tun:
#!/bin/sh
git fetch upstream
if [ `git rev-list HEAD...upstream/master --count` -eq 0 ]
then
echo "all the same, do nothing"
else
echo "update exist, let's pull"
git pull upstream master
git Push Origin master
fi