Was ist der Unterschied zwischen "git pull" und "git fetch"?

• 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:

• Wenn Sie einen 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.
• Wenn Sie einen 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.

Manchmal hilft eine visuelle Darstellung.

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. 

1. Aktualisieren Sie Ihr lokales Repo von der Fernbedienung aus (aber führen Sie keine Zusammenführung durch):

   git fetch 
   

2. Nachdem Sie die Updates heruntergeladen haben, sehen Sie die Unterschiede:

   git diff master Origin/master 
   

3. 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 pullautomatisch 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:

git holen

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.

git ziehen

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."

Bonus:

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:

• Performance (scrollen Sie durch alle Commits und Nachrichten, ohne zu versuchen, es durch das Netzwerk zu drücken)
• Feedback über den Status Ihres lokalen Repos (zum Beispiel verwende ich Atlassians SourceTree, wodurch mir eine Glühbirne angezeigt wird, die angibt, ob ich im Vergleich zum Origin vor oder hinter mich verpflichtet bin. Diese Informationen können mit einem GIT FETCH aktualisiert werden ).

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:

1. 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]

2. 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:

1. Verzweigen Sie den lokalen Zweig nach dem letzten gemeinsamen Vorfahren und fügen Sie neue Commits parallel zu Commits hinzu, die für das lokale Repository eindeutig sind. 
2. Fügen Sie neue Commits nach dem letzten gemeinsamen Vorfahren ein und wenden Sie Commits erneut an, die im lokalen Repository eindeutig sind.

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 und git 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: 

1. git fetch: Git wird die neueste Version von Remote zu Local bringen, aber nicht automatisch zusammenführen . git fetch Origin mastergit log -p master..Origin/mastergit 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. 

2. 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 Befehl git 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 von git 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 --allcommand 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 repositorybranch-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 developbranch 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:

• Sie bekommen keine Isolation. 
• Es wirkt sich auf Ihre lokale Entwicklung aus.
• Es muss nicht explizit ausgecheckt werden. Weil es implizit einen git merge tut.
• Es ist im Grunde NICHT sicher. Es ist aggressiv.
• Im Gegensatz zu git fetch, wo nur Ihr .git/refs/remotes wirkt, wirkt sich git pull sowohl auf .git/refs/remotesund.git/refs/heads/ aus.

Hmmm ... wenn ich also die Arbeitskopie nicht mit 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: 

1. ls. Dadurch werden die Dateien und Verzeichnisse angezeigt. Nichts cooles, ich weiß.

2. Jetzt ls -a. Dies zeigt dot files ie Dateien, die mit . beginnen. Sie können dann ein Verzeichnis mit dem Namen: .git sehen. 

3. cd .git. Dies wird natürlich Ihr Verzeichnis ändern. 
4. Jetzt kommt der lustige Teil; do ls. Sie sehen eine Liste von Verzeichnissen. Wir suchen nach refs. cd refs.
5. Es ist interessant zu sehen, was sich in allen Verzeichnissen befindet, aber konzentrieren wir uns auf zwei davon. heads und remotes. Verwenden Sie cd, um auch in ihnen nachzuschauen. 
6. Jeder git fetch, den Sie tun, aktualisiert Elemente im /.git/refs/remotes-Verzeichnis. Es wird nichts im Verzeichnis /.git/refs/heads aktualisiert.
7. ANY 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