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

Hinweis des Moderators Da bereits 67 Antworten auf diese Frage gesendet wurden (einige wurden gelöscht), sollten Sie überlegen, ob Sie etwas Neues hinzufügen, bevor Sie eine weitere senden.

Was sind die Unterschiede zwischen git pull und git fetch ?

10.500
15 нояб. set puppeno 15 nov. 2008-11-15 12:51 08 um 12:51 2008-11-15 12:51
@ 46 Antworten
  • 1
  • 2

In den einfachsten Ausdrücken führt git pull einen git fetch gefolgt von git merge .

Sie können git fetch jederzeit refs/remotes/<remote>/ , um die Remote-Tracking-Zweige in refs/remotes/<remote>/ zu aktualisieren.

Diese Operation ändert niemals Ihre eigenen lokalen Niederlassungen in den refs/heads und ist sicher, ohne die Arbeitskopie zu ändern. Ich habe sogar gehört, dass die Leute regelmäßig git fetch in einem cron-Job im Hintergrund laufen lassen (obwohl ich es nicht empfehlen würde).

Ein git pull ist das, was Sie tun würden, um den lokalen Zweig mit Ihrer Remote-Version und andere Fernverfolgungs-Zweige zu aktualisieren.

Git-Dokumentation: Git Pull

8755
15 нояб. Antwort von Greg Hewgill 15. November 2008-11-15 12:52 08 um 12:52 2008-11-15 12:52
  • Wenn Sie pull , versucht Git, Ihre Arbeit automatisch für Sie auszuführen. Da dies kontextsensitiv ist , führt Git alle Push-Commits in den Zweig ein, an dem Sie gerade arbeiten. pull automatisch Commits zusammen, ohne dass Sie sie zuerst sehen . Wenn Sie Ihre Filialen nicht besonders gut verwalten können, kann dies zu häufigen Konflikten führen.

  • Beim Abholen sammelt Git alle Commits aus dem Zielzweig, die in Ihrem aktuellen Zweig nicht vorhanden sind, speichern sie jedoch in Ihrem lokalen Repository . Sie werden jedoch nicht mit Ihrem aktuellen Zweig kombiniert . Dies ist besonders nützlich, wenn Sie Ihr Repository ständig aktualisieren müssen, aber daran arbeiten, was beim Aktualisieren Ihrer Dateien möglicherweise kaputt geht. Um Commits in den Hauptzweig zu integrieren, verwenden Sie die merge .

border=0
1919
18 авг. Antwort von Mouna Cheikhna 18 Aug. 2011-08-18 11:53 '11 am 11:53 2011-08-18 11:53

Es ist wichtig, die Git-Design-Philosophie der Philosophie eines traditionelleren Source-Management-Tools wie SVN gegenüberzustellen.

Subversion wurde unter Verwendung eines Client / Server-Modells entworfen und erstellt. Es gibt ein Repository, bei dem es sich um einen Server handelt, und mehrere Clients können Code vom Server extrahieren, damit arbeiten und ihn dann zurück an den Server übertragen. Es wird davon ausgegangen, 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 (obwohl Sie es auf jeden Fall verwenden können, wenn Sie möchten). Git wurde auch so konzipiert, dass Client und Server nicht gleichzeitig online sein sollten. Git wurde so konzipiert, dass Personen mit einem unzuverlässigen Link sogar per E-Mail Code austauschen können. Sie können die Arbeit vollständig deaktivieren und eine CD brennen, um über git Code 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 Speichern einer Kopie des Remote-Repositorys kann git die erforderlichen Änderungen feststellen, auch wenn das Remote-Repository nicht verfügbar ist. Wenn Sie später Änderungen an eine andere Person senden müssen, kann git diese Änderungen ab dem Zeitpunkt, den Sie mit dem Remote-Repository kennen, als Änderungssatz übertragen.

  • git fetch ist ein Befehl, der besagt: "Bringen Sie meine lokale Kopie des Remote-Repositorys auf den neuesten Stand."

  • git pull sagt: "Änderungen in das Remote-Repository bringen, wo ich meinen eigenen Code verwahre."

Normalerweise führt git pull dazu git fetch , um eine lokale Kopie des Remote-Repositorys zu aktualisieren, und führt die Änderungen anschließend in Ihr eigenes Code-Repository und möglicherweise in Ihre Arbeitskopie ein.

Entfernen Sie dies, um zu berücksichtigen, dass sich auf Ihrer Workstation häufig mindestens drei Kopien des Projekts befinden. Eine Kopie ist Ihr eigenes Repository mit einem eigenen Commit-Verlauf. Die zweite Kopie ist Ihre Arbeitskopie, in der Sie bearbeiten und erstellen. Die dritte Kopie ist Ihre lokale "zwischengespeicherte" Kopie des Remote-Repositorys.

1066
31 марта '13 в 21:43 2013-03-31 21:43 Die Antwort gibt MikeD am 31. März 13 um 21:43 Uhr 2013-03-31 21:43
711
09 июня '15 в 16:30 2015-06-09 16:30 Die Antwort wird gegeben Contango 09. Juni '15 um 16:30 Uhr 2015-06-09 16:30

git fetch zum Beispiel die folgende Meldung, die Sie über alle Änderungen im Remote-Zweig seit dem letzten git fetch Sie können also vor dem eigentlichen git fetch überprüfen, ob die Dateien in Ihrem aktuellen Zweig geändert und eine Kopie ausgeführt werden können .

 git fetch git diff ...origin 
437
07 мая '10 в 22:23 2010-05-07 22:23 Die Antwort wird mepster am 07. Mai '10 um 22:23 Uhr gegeben

Ich musste ein bisschen verstehen, was der Unterschied war, aber das ist eine einfache Erklärung. master in Ihrem localhost ist ein Zweig.

Wenn Sie ein Repository klonen, erhalten Sie das gesamte Repository für den lokalen Host. Dies bedeutet, dass Sie zu diesem Zeitpunkt den Ursprungs- / Master-Zeiger auf HEAD und der Master auf denselben HEAD .

Wenn Sie anfangen zu arbeiten und dies tun, übertragen Sie den Master-Zeiger auf HEAD + Ihre Fixierungen. Der Ursprungs- / Master-Zeiger zeigt jedoch immer noch an, was beim Klonen war.

Der Unterschied wird also sein:

  • Wenn Sie git fetch ausführen, werden einfach alle Änderungen im Remote-Repository ( GitHub ) extrahiert und der Start- / Master-Zeiger auf HEAD . In der Zwischenzeit zeigt der lokale Zweigassistent weiterhin an, wo er sich befindet.
  • Wenn Sie git pull , werden im Wesentlichen (wie zuvor erläutert) alle Änderungen in den Hauptzweig eingefügt und der Zeiger auf HEAD .
347
11 мая '12 в 21:37 2012-05-11 21:37 Die Antwort wird gegeben Gerardo 11. Mai '12 um 21:37 2012-05-11 21:37

Manchmal hilft eine visuelle Präsentation.

2019

25 янв. die antwort wird von dem Fahrgast 25 jan gegeben. 2016-01-25 20:28 '16 um 20:28 Uhr 2016-01-25 20:28

kurz

git fetch ist ähnlich wie pull , wird jedoch nicht zusammengeführt. d.h. Es extrahiert Remote-Aktualisierungen ( refs und objects ), aber Ihr lokales refs bleibt unverändert (d. origin/master aktualisiert, aber master bleibt unverändert).

git pull von der Konsole abgeworfen und fügt sich sofort zusammen.

Mehr

git clone Klone Repos.

git rebase speichert Material aus Ihrem aktuellen Zweig, der sich nicht im aufsteigenden Zweig befindet, im temporären Bereich. Ihr Thread ist jetzt derselbe wie vor Beginn Ihrer Änderungen. Daher git pull -rebase die gelöschten Änderungen heraus, spult den lokalen Zweig zurück und wiederholt die Änderungen oben im aktuellen Zweig nacheinander, bis Sie mit den neuesten Entwicklungen git pull -rebase sind.

git branch -a zeigt Ihnen außerdem genau, was mit all Ihren Zweigstellen geschieht - lokal und remote.

Dieser Blogeintrag war hilfreich:

Unterschied zwischen git pull, git fetch und git clone (und git rebase) - Mike Pierce

und deckt git pull , git fetch , git clone und git rebase .

====

UPDATE

Ich dachte, ich würde es aktualisieren, um zu zeigen, wie Sie es in der Praxis tatsächlich verwendet haben.

  1. Aktualisieren Sie Ihr lokales Repo von einem Remote-Gerät aus (aber vereinigen Sie es nicht):

     git fetch 
  2. Nach dem Herunterladen von Updates 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:

In Schritt 2: Weitere Informationen zu den Unterschieden zwischen lokalen und Remote-Geräten finden Sie unter Abschnitt: So vergleichen Sie einen lokalen Git-Zweig mit einem Remote-Zweig.

In Schritt 3: Am wahrscheinlichsten ist es (z. B. in einem sich schnell ändernden Repo) git rebase origin zu git rebase origin . Siehe @Justin Ohms Comment in einer anderen Antwort.

Siehe auch: http://longair.net/blog/2009/04/16/git-fetch-and-merge/

170
13 апр. Antwort Snowcrash 13. April 2013-04-13 20:31 '13 um 20:31 Uhr 2013-04-13 20:31
 git-pull - holt ein anderes Repository oder eine lokale Niederlassung und führt dieses zusammen SYNOPSIS git ziehen ... BESCHREIBUNG Führt den Git-Fetch aus  abgerufenen Kopf (s) in den aktuellen Zweig.  Ruft mit --rebase git-rebase auf  anstelle von git-merge. Beachten Sie, dass Sie verwenden können.  (aktuelles Verzeichnis) als <Repository> zum Abrufen  aus dem lokalen Repository - Dies ist nützlich, wenn Sie lokale Zweige zusammenführen  in den aktuellen Zweig. Git-Pull  für git-fetch.

Sie würden ziehen, wenn Sie möchten, dass die Geschichten zusammengeführt werden, würden Sie es bekommen, wenn Sie nur "den Code wollen", weil einige von ihnen einige Artikel hier veröffentlichen.

161
15 нояб. Antwort von Vinko Vrsalovic 15. November 2008-11-15 12:52 08 um 12:52 2008-11-15 12:52

Sie können aus dem Remote-Repository extrahieren, die Unterschiede sehen und dann ziehen oder zusammenführen.

Dies ist ein Beispiel für ein Remote-Repository mit dem Namen origin und einen Zweig mit dem Namen master , der den entfernten origin/master Zweig verfolgt:

 git checkout master git fetch git diff origin/master git rebase origin master 
147
21 марта '11 в 14:07 2011-03-21 14:07 Die Antwort wird von Antonio Bardazzi 21. März 11 um 14:07 gegeben 2011-03-21 14:07

Die kurze und einfache Antwort ist, dass git pull nur git fetch gefolgt von git merge .

Es ist sehr wichtig zu beachten, dass git pull automatisch zusammengeführt wird, ob Sie es möchten oder nicht . Dies kann natürlich zu Mischkonflikten führen. Nehmen wir an, Ihre Konsole ist origin und Ihr Zweig ist master . Wenn Sie vor dem Ziehen git diff origin/master , sollten Sie sich der möglichen Konflikte bei der Zusammenführung bewusst sein und Ihre Zweigstelle entsprechend vorbereiten.

Neben dem Ziehen und Klicken enthalten einige Workflows auch git rebase , zum Beispiel dieses, das ich aus einem verwandten Artikel git rebase :

 git pull origin master git checkout foo-branch git rebase master git push origin foo-branch 

Wenn Sie sich in dieser Situation befinden, werden Sie möglicherweise von git pull --rebase versucht. Wenn Sie wirklich nicht wissen, was Sie tun, würde ich Ihnen raten, es zu tun. Dies ist eine Warnung aus der Manpage für git-pull , Version 2.3.5 :

Dies ist eine potenziell gefährliche Betriebsart. Er schreibt eine Geschichte um, die nicht gut aussieht, wenn Sie diese Geschichte bereits veröffentlicht haben. Verwenden Sie diesen Parameter nicht, wenn Sie git-rebase (1) nicht sorgfältig gelesen haben.

139
15 мая '11 в 23:53 2011-05-15 23:53 Die Antwort wird von jfmercer am 15. Mai 11 um 23:53 Uhr 2011-05-15 23:53 gegeben

2019

117
06 февр. Die Antwort wird in der Regel am 6. Februar gegeben. 2015-02-06 14:48 '15 am 14:48 2015-02-06 14:48

Nun , hier sind ein paar Informationen zu git pull und git fetch , damit Sie die tatsächlichen Unterschiede verstehen können ... fetch ruft in ein paar einfachen Worten die neuesten Daten ab, ändert jedoch nicht den Code und kontaktiert nicht Ihren aktuellen lokalen Filialcode, sondern zieht den Code mit den Änderungen heraus und führen Sie es in Ihre lokale Niederlassung ein. Lesen Sie weiter, um genauere Informationen zu erhalten:

git holen

Es werden alle Links und Objekte sowie alle neuen Zweige in Ihr lokales Repository heruntergeladen ...

Wählen Sie aus einem oder mehreren anderen Repositories Verzweigungen und / oder Tags (zusammen "refs") aus, zusammen mit den Objekten, die zur Vervollständigung ihrer Storys erforderlich sind. Fernverfolgungszweige wurden aktualisiert (siehe Beschreibung unten, um dieses Verhalten zu steuern).

Standardmäßig wird auch jedes Tag abgerufen, das auf extrahierte Storys verweist. Dadurch werden Tags extrahiert, die auf die Zweige verweisen, an denen Sie interessiert sind. Dieses Standardverhalten kann mit den Optionen --tags oder --no-tags oder durch Festlegen des remote..tagOpt geändert werden. Mit refspec, das Tags explizit extrahiert, können Sie Tags extrahieren, die nicht auf die Zweige zeigen, an denen Sie interessiert sind.

git fetch kann von einem einzigen benannten Repository oder einer URL oder, falls vorhanden, aus mehreren Repositorys gleichzeitig abgerufen werden, und es gibt Konsolen. in die Konfigurationsdatei schreiben (Siehe Git-config 1 ).

Wenn kein Remote-Gerät angegeben ist, wird die Standardstartquelle verwendet, es sei denn, ein Upstream-Zweig ist für den aktuellen Zweig konfiguriert.

Die Namen der ausgewählten Links sowie die Namen der Objekte, auf die sie zeigen, werden in.git / FETCH_HEAD aufgezeichnet. Diese Informationen können von Skripts oder anderen git-Befehlen verwendet werden, z. B. git-pull.


git ziehen

Es werden Änderungen vom entfernten zum aktuellen Zweig in lokaler ...

Umfasst Änderungen von einem Remote-Repository zum aktuellen Zweig. Im Standardmodus ist git pull eine Abkürzung für git fetch, gefolgt von git merge FETCH_HEAD.

Insbesondere führt git pull git fetch mit den angegebenen Parametern aus und ruft git merge auf, um die empfangenen Zweigheader mit dem aktuellen Zweig zusammenzuführen. Mit --rebase wird git rebase statt git merge ausgeführt.

sollte der Name des Remote-Repositorys sein, das an git-fetch 1 übergeben wird . Sie können einen beliebigen Remote-Ref (zum Beispiel den Tag-Namen) oder sogar eine Sammlung von Links mit entsprechenden Remote-Tracking-Zweigen (zum Beispiel Refs / Heads: refs / Remotes / Origin /) aufrufen. Dies ist jedoch normalerweise der Name des Asts im Remote-Repository.

Die Standardwerte für und werden aus den Konfigurationen "remote" und "merge" für den aktuellen Zweig gelesen, wie von git-branch --track festgelegt.


Ich erstelle unten ein visuelles Bild, um zu zeigen, wie git fetch und git pull zusammenarbeiten ...

2019

Bonus:

Wenn ich in den obigen Antworten vom Dehnen und Extrahieren 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 neue Commits an den Server senden, probieren Sie diesen Befehl aus. Er synchronisiert automatisch die neuesten Serveränderungen (mithilfe von fetch + merge) und fügt Ihre Nachricht am Anfang in das git-Protokoll ein. Sie brauchen sich keine Sorgen über das Ziehen / Zusammenführen von Hand zu machen.

Informationen finden Sie unter: http://gitolite.com/git-pull--rebase

113
23 дек. Die Antwort wird von Sazzad Hissain Khan am 23. Dezember gegeben. 2015-12-23 18:31 '15 am 18:31 2015-12-23 18:31

Ich mag eine Art visuelle Darstellung der Situation, um diese Dinge zu verstehen. Vielleicht würden andere Entwickler das auch gerne sehen, daher hier mein Zusatz. Ich bin mir nicht ganz sicher, ob alles korrekt ist, kommentieren Sie dies bitte, 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 . . . FETCH *------------------>* Your local cache of the remote is updated with the origin (or multiple external sources, that is git 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 der Hauptvorteile eines Konsolenspiegelbildes sind:

  • Leistung (Scrollen aller Commits und Nachrichten, ohne zu versuchen, sie über das Netzwerk zu komprimieren)
  • Rückmeldung über den Status Ihres lokalen Repos (beispielsweise verwende ich Atlassian SourceTree, wodurch eine Glühbirne angezeigt wird, die angibt, ob ich im Vergleich zur Quelle vorwärts oder rückwärts gehen möchte. Update mit GIT FETCH).
107
20 февр. Die Antwort wird von Justus Romijn am 20. Februar gegeben. 2014-02-20 00:18 '14 am 0:18 2014-02-20 00:18

Ich habe auch damit zu kämpfen. Tatsächlich bin ich hier mit der Google-Suche nach genau derselben Frage gekommen. Nachdem ich all diese Antworten gelesen hatte, zeichnete ich endlich ein Bild in meinem Kopf und beschloss, mich mit dem Zustand von 2 Repositories und 1 Sandbox sowie den mit der Zeit durchgeführten Aktionen zu beschäftigen und deren Version zu beobachten. So kam ich dazu. Bitte korrigieren Sie mich, wenn ich versagt habe.

Drei Repositories mit einer Probe:

 --------------------- ----------------------- ----------------------- - 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+ - --------------------- ----------------------- ----------------------- 

Drei Repositories mit einer Last

 --------------------- ----------------------- ----------------------- - 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 hat mir geholfen zu verstehen, warum das Sampling so wichtig ist.

95
17 июля '12 в 19:43 2012-07-17 19:43 Die Antwort wird gegeben PN1 Dude 17. Juli 12 um 19:43 Uhr 2012-07-17 19:43

Der Unterschied zwischen GIT Fetch und GIT Pull kann durch das folgende Szenario erklärt werden: (Denken Sie daran, dass die Bilder mehr sprechen als Worte! Ich habe eine grafische Darstellung geliefert)

Nehmen wir an, Sie arbeiten mit Mitgliedern Ihres Teams an einem Projekt. Daher sind sie eine der Hauptabteilungen des Projekts, und alle Teilnehmer müssen in ihr eigenes lokales Repository verzweigen und dann an diesem lokalen Zweig arbeiten, um Module zu ändern / hinzuzufügen, und dann zum Hauptzweig zurückkehren.

Der Ausgangszustand der beiden Zweige, wenn Sie das Hauptprojekt in Ihrem lokalen Repository verzweigen, wird folgendermaßen aussehen: ( A , B und C sind die bereits im Projekt abgeschlossenen Module).

2019

07 февр. Die Antwort wird von Aman Tiwari 07 Feb. gegeben. 2017-02-07 17:15 '17 um 17:15 Uhr 2017-02-07 17:15

Wir sagen nur:

 git pull == git fetch + git merge 

Если вы запустите git pull , вам не нужно объединять данные с локальными. Если вы запустите git fetch , это означает, что вы должны запустить git merge для получения последнего кода на вашем локальном компьютере. В противном случае локальный машинный код не будет изменен без слияния.

Итак, в Git Gui, когда вы делаете выборку, вам нужно объединить данные. Извлечь сам себя не приведет к изменению кода на вашем локальном компьютере. Вы можете проверить, что при обновлении кода путем выборки после извлечения и просмотра; код он не изменится. Затем вы объединяетесь... Вы увидите измененный код.

79
ответ дан Selvamani 21 февр. '13 в 16:25 2013-02-21 16:25

git fetch выводит код с удаленного сервера на ваши ветки отслеживания в локальном репозитории. Если ваш пульт называется origin (по умолчанию), то эти ветки будут находиться в пределах origin/ , например origin/master , origin/mybranch-123 и т.д. Это не ваши текущие ветки, они являются локальными копиями этих ветвей из сервер.

git pull делает git fetch , но затем также объединяет код из ветки отслеживания в вашу текущую локальную версию этой ветки. Если вы еще не готовы к этим изменениям, сначала git fetch .

77
ответ дан Michael Durrant 19 сент. '13 в 23:01 2013-09-19 23:01

git fetch будет извлекать удаленные ветки, чтобы вы могли git diff или git merge их с текущей ветвью. git pull будет запускать выборку на удаленном плече, отслеживаемом текущей ветвью, а затем слить результат. Вы можете использовать git fetch , чтобы узнать, есть ли какие-либо обновления удаленной ветки без необходимости их слияния с вашей локальной ветвью.

73
ответ дан ntanase 27 нояб. '12 в 0:58 2012-11-27 00:58

Git Fetch

Вы загружаете изменения в локальную ветку из источника через выборку. Fetch запрашивает удаленное репо для всех коммитов, которые сделали другие, но у вас нет на вашем локальном репо. Fetch загружает эти коммиты и добавляет их в локальный репозиторий.

Git Слияние

Вы можете применить изменения, загруженные через выборку, с помощью команды merge. Merge берет полученные из выборки коммиты и пытается добавить их в локальную ветку. Слияние будет сохранять историю фиксации ваших локальных изменений, так что, когда вы делитесь своей веткой с push, Git будет знать, как другие могут объединить ваши изменения.

Git Pull

Считать и слить вместе достаточно часто, чтобы была создана команда, которая объединяет два, pull. Pull делает выборку, а затем слияние, чтобы добавить загруженные коммиты в вашу локальную ветвь.

69
ответ дан Pinkesh Sharma 14 июля '16 в 0:23 2016-07-14 00:23

Единственное различие между git pull и git fetch заключается в следующем:

git pull извлекает из удаленной ветки и объединяет его.

git fetch извлекает только из удаленной ветки, но не объединяется

also. git pull = git fetch + git merge...

47
ответ дан Rohitashv Singhal 04 июня '13 в 17:08 2013-06-04 17:08

Git позволяет хронологически более старые коммиты применяться после того, как новые коммиты. Из-за этого акт передачи фиксации между репозиториями делится на два этапа:

  • Копирование новых коммитов из удаленной ветки для копирования этой удаленной ветки внутри локального репо.

    (операция репо для операции репо) master@remote >> remote/origin/master@local

  • Интеграция новых коммитов в локальную ветвь

    (операция внутри-репо) remote/origin/master@local >> master@local

Есть два способа сделать шаг 2. Вы можете:

  • Вилка локального ветки после последнего общего предка и добавление новых коммитов, параллельных коммитам, которые уникальны для локального репозитория, финализируются путем слияния фиксации, закрытия вилки.
  • Вставить новые коммиты после последнего общего предка и повторно применить к локальному репозиторию.

В терминологии git шаг 1 равен git fetch , шаг 2 равен git merge или git rebase

git pull составляет git fetch и git merge

42
ответ дан Pawel Furmaniak 28 нояб. '13 в 20:03 2013-11-28 20:03

В чем разница между git pull и git fetch ?

Чтобы понять это, вам сначала нужно понять, что ваш локальный git поддерживает не только ваш локальный репозиторий, но также поддерживает локальную копию удаленного репозитория.

git fetch обновляет локальную копию удаленного репозитория. Например, если ваш удаленный репозиторий - это GitHub - вы можете захотеть извлечь любые изменения, сделанные в удаленном репозитории, в локальную копию этого удаленного хранилища. Это позволит вам выполнять такие операции, как сравнение или слияние.

git pull , с другой стороны, приведет к смене изменений в удаленном репозитории, где вы сохраните свой собственный код. Как правило, git pull сначала выполнит git fetch , чтобы обновить локальную копию удаленного репозитория, а затем объединить изменения в свой собственный репозиторий кода и, возможно, вашу рабочую копию.

35
ответ дан Donal 19 мая '15 в 14:57 2015-05-19 14:57

Git получает ветку последней версии от удаленного к локальному, используя две команды:

  • git fetch: Git собирается получить последнюю версию с удаленного на локальный, но она не будет автоматически сливаться. git fetch origin master git log -p master..origin/master git merge origin/master

    Приведенные выше команды означают, что загружать последнюю версию основной ветки из источника из удаленной в исходную ветвь оригинала. А затем сравнивает локальную ветвь ведущей ветки и начальную ветвь. Наконец, слейте.

  • Git pull: Git собирается получить последнюю версию с пульта и слить в локальный.

    git pull origin master

    Приведенная выше команда эквивалентна git fetch и git merge . На практике git fetch может быть более безопасным, поскольку перед слиянием мы можем видеть изменения и решать, сходиться ли.

33
ответ дан Marcus Thornton 12 авг. '14 в 7:00 2014-08-12 07:00

git pull == (git fetch + git merge)

git fetch не изменяется на локальные ветки.

Если у вас уже есть локальный репозиторий с удаленной настройкой для желаемого проекта, вы можете захватить все ветки и теги для существующего удаленного с помощью git fetch.... Fetch не вносит никаких изменений в локальные ветки, поэтому вам необходимо объединить удаленную ветку с парным локальным ветвью для включения новых изменений извлечения. из github

31
ответ дан Iggy 20 сент. '13 в 1:41 2013-09-20 01:41

Попытка быть понятной и простой.

Команда git pull на самом деле является shortcut для git fetch , за которой следует git слияние или git rebase в зависимости от вашей конфигурации. Вы можете настроить репозиторий Git, чтобы git pull - выборка, за которой следует rebase.

30
ответ дан montells 29 июля '15 в 21:38 2015-07-29 21:38

Фактически Git хранит копию вашего собственного кода и удаленный репозиторий.

Команда git fetch обновляет локальную копию, получая данные из удаленного репозитория. Причина, по которой мы нуждаемся в этом, - это то, что кто-то другой мог внести некоторые изменения в код, и вы хотите сохранить себя обновленным.

Команда git pull приносит изменения в удаленном репозитории, где вы храните свой собственный код. Обычно git pull делает это, делая сначала

30
ответ дан Pokemon 13 сент. '15 в 21:48 2015-09-13 21:48

Простое графическое представление для начинающих,

2019

ответ дан Mohideen ibn Mohammed 12 июля '17 в 9:23 2017-07-12 09:23
 git pull = git fetch + git merge 
28
ответ дан Saqib R. 12 июля '15 в 6:54 2015-07-12 06:54
  • 1
  • 2

Другие вопросы по меткам или Задайте вопрос