remote - git push




Was ist der Unterschied zwischen "git pull" und "git fetch"? (20)

Moderator-Hinweis: Da dieser Frage bereits 67 Antworten zur Verfügung gestellt wurden (einige von ihnen wurden gelöscht), sollten Sie überlegen, ob Sie etwas Neues beitragen oder nicht, bevor Sie eine weitere posten.

Was sind die Unterschiede zwischen git pull und git fetch ?


Was ist der Unterschied zwischen git pullund 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 fetchbringt 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 pullAuf der anderen Seite werden die Änderungen im Remote-Repository dahin gehoben, wo Sie Ihren eigenen Code aufbewahren. Normalerweise git pullwird git fetchzuerst die lokale Kopie des Remote-Repositorys auf den neuesten Stand gebracht. Anschließend werden die Änderungen in Ihrem eigenen Code-Repository und möglicherweise in Ihrer Arbeitskopie zusammengeführt.


Bonus:

In den obigen Antworten möchte ich mit Pull & Fetch 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 platzieren. Sie müssen sich keine Gedanken über manuelles Ziehen / Zusammenführen machen.

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


Ein Anwendungsfall von git fetch besteht darin, dass Sie im Folgenden alle Änderungen im Remote-Zweig seit Ihrem letzten git fetch erfahren. Sie können also vor dem eigentlichen git fetch prüfen, ob Dateien in Ihrem aktuellen Zweig und in Ihrer 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 Ursprungs- / Master-Zeiger auf HEAD und Master auf denselben HEAD .

Wenn Sie anfangen zu arbeiten und Commits ausführen, HEAD Sie den Master-Zeiger zu HEAD + Ihren Commits. Der Ursprungs- / Master-Zeiger zeigt jedoch immer noch auf das, was beim Klonen war.

Der Unterschied wird also sein:

  • Wenn Sie einen git fetch , werden nur alle Änderungen im Remote-Repository ( GitHub ) GitHub und der Ursprungs- / Master-Zeiger auf HEAD . In der Zwischenzeit wird Ihr lokaler Zweigmeister weiterhin auf den aktuellen Standort zeigen.
  • Wenn Sie einen git pull , werden im Wesentlichen (wie zuvor erläutert) Abrufen und neue Änderungen in Ihrem Hauptzweig zusammengeführt und der Zeiger auf HEAD .


In den einfachsten Ausdrücken macht git pull einen git fetch gefolgt von einem git merge .

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

Diese Operation ändert niemals eigene Zweigstellen unter refs/heads und ist ohne Änderung der Arbeitskopie sicher durchzuführen. Ich habe sogar von Leuten gehört, die git fetch regelmäßig in einem Cron-Job im Hintergrund laufen ließen (obwohl ich das nicht empfehlen würde).

Ein git pull ist das, was Sie tun würden, um einen lokalen Zweig mit seiner Remote-Version auf den neuesten Stand zu bringen, während Sie auch Ihre anderen Remote-Tracking-Zweige aktualisieren.

Git-Dokumentation: Git Pull


Sie können aus einem Remote-Repository abrufen, die Unterschiede anzeigen 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 origin/master des Remote-Zweigs verfolgt:

git checkout master                                                  
git fetch                                        
git diff origin/master
git rebase origin master

git fetchruft den Code vom Remote-Server auf Ihre Nachverfolgungszweige in Ihrem lokalen Repository herunter. Wenn Ihre Remote - Name origin(der Standard) , dann werden diese Zweige innerhalb sein origin/, zum Beispiel origin/master, origin/mybranch-123etc. Diese sind nicht Ihre Stromzweige, sie sind lokale Kopien dieses Zweiges vom Server.

git pullführt ein git fetch, führt dann aber auch den Code aus dem Tracking-Zweig in Ihre aktuelle lokale Version dieses Zweiges ein. Wenn Sie noch nicht bereit sind, diese Änderungen vorzunehmen, müssen Sie git fetchzuerst beginnen.


Git-Abruf

Sie laden Änderungen vom Ursprung aus durch Abrufen in Ihre lokale Zweigstelle ein. 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 für Push freigeben.

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.


Kurz

git fetch ist ähnlich wie pull , geht aber nicht zusammen. Das heißt, es werden Remote-Aktualisierungen ( refs und objects ) abgerufen, Ihr lokales refs bleibt jedoch gleich (dh origin/master wird aktualisiert, master bleibt jedoch gleich).

git pull zieht von einer Fernbedienung nach unten und fügt sich sofort ein.

Mehr

git clone klont ein repo.

git rebase speichert git rebase aus Ihrem aktuellen Zweig, die sich nicht im Upstream-Zweig befinden, in einem temporären Bereich. Ihr Zweig ist jetzt derselbe wie vor Beginn der Änderungen. So git pull -rebase die Remote-Änderungen herunter git pull -rebase den lokalen Zweig zurück und spielt Ihre Änderungen über dem aktuellen Zweig nacheinander ab, bis Sie auf dem neuesten Stand sind.

git branch -a zeigt Ihnen auch genau, was in Ihren Filialen vor Ort und in der Ferne passiert.

Dieser Blogeintrag war nützlich:

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

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

====

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 holen

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

    git diff master herkunft / master

  3. Wenn Sie mit diesen Updates zufrieden sind, führen Sie Folgendes aus:

    git ziehen

Anmerkungen:

Zu Schritt 2: Weitere Informationen zu Unterschieden zwischen lokalen und Remotes finden Sie unter: Vergleichen Sie den lokalen Git-Zweig mit dem Remote-Zweig.

Zu Schritt 3: Es ist wahrscheinlich genauer (z. B. bei einem sich schnell ändernden Repo), hier einen git rebase origin . Siehe @Justin Ohms Kommentar in einer anderen Antwort.

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


Eine einfache grafische Darstellung für Anfänger

Hier,

git pull  

holt Code aus dem Repository und rebase mit Ihrem lokalen ... in git pull können neue Commits erstellt werden.

aber in ,

git holen

holt Code aus dem Repository und wir müssen ihn manuell mit Hilfe von git rebase

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 Ursprung, Ihr Remote-Repo- Master ist Ihre Niederlassung

2) git fetch (manuell neu abstimmen müssen):

git fetch origin master

Server-Änderungen werden vom Ursprung 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 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 es wird nicht automatisch zusammengeführt. git fetch origin master git log -p master..origin/master git merge origin/master

    Die obigen Befehle bedeuten, dass die neueste Version des Hauptzweigs vom Ursprungsort zum Ursprungshauptzweig heruntergeladen wird. Und vergleicht dann den lokalen Hauptzweig und den Ursprungshauptzweig. Schließlich verschmelzen.

  2. git pull: Git holt die neueste Version von der Fernbedienung und mischt sie mit der lokalen Version zusammen.

    git pull origin master

    Der obige Befehl ist das Äquivalent zu git fetchund git merge. In der Praxis git fetchvielleicht sicherer, weil wir vor dem Zusammenführen die Änderungen sehen und entscheiden können, ob sie zusammengeführt werden sollen.


Versuchen, klar und einfach zu sein.

Der Befehl git pull ist eigentlich ein shortcutfor git-Abruf, gefolgt von der git-Zusammenführung oder dem git rebase- Befehl, abhängig von Ihrer Konfiguration. Sie können Ihr Git-Repository so konfigurieren, dass git pull ein Abruf ist, gefolgt von einer Rebase.


Wir sagen einfach:

git pull == git fetch + git merge

Wenn Sie ausführen git pull, müssen Sie die Daten nicht mit dem lokalen zusammenführen. Wenn Sie ausführen git fetch, müssen Sie ausführen , git mergeum 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 bei Ihrem lokalen Benutzer durch. Sie können dies überprüfen, wenn Sie den Code aktualisieren, indem Sie einmal holen, holen und sehen; Der Code ändert sich nicht. Dann mischen Sie zusammen ... Sie sehen den geänderten Code.


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


Der Unterschied zwischen GIT Fetch und GIT Pull kann mit dem folgenden Szenario erklärt werden: (Denken Sie daran, dass Bilder mehr sprechen als Worte!

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 ihrem eigenen lokalen Repository zusammenfassen und dann an diesem lokalen Zweig arbeiten, um Module zu ändern / hinzuzufügen, und dann zum Hauptzweig zurückkehren.

Der Anfangszustand der beiden Zweige, wenn Sie das Hauptprojekt in Ihrem lokalen Repository aufgespalten haben A, wird wie folgt aussehen ( Bund Csind bereits abgeschlossene Module des Projekts).

Jetzt haben Sie mit der Arbeit an dem neuen Modul begonnen (angenommen D) und wenn Sie das DModul abgeschlossen haben, möchten Sie es in den Hauptzweig verschieben. In der Zwischenzeit passiert jedoch, dass einer Ihrer Teamkollegen ein neues Modul Eentwickelt Fund modifiziert hat C.
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 Dzu Fehlfunktionen Ihres Moduls führen .

Um solche Probleme zu vermeiden und parallel zum ursprünglichen Projektfortschritt zu arbeiten, gibt es zwei Möglichkeiten:

1. Git Fetch - Dies lädt alle Änderungen herunter, die am Ursprungs- / Hauptzweigprojekt vorgenommen wurden, die 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 modifizieren, Dwenn dies erforderlich ist C.

2. Git Pull- Dies aktualisiert Ihren lokalen Zweig mit dem Ursprungs- / Hauptzweig, dh es wird eine Kombination aus Git Fetch und Git Merge nacheinander ausgeführt. Dies kann jedoch zu Konflikten führen. Daher wird empfohlen, Git Pull mit einer sauberen Kopie zu verwenden.


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 zur Kopie dieses Remote-Zweigs innerhalb des lokalen Repos.

    (Repo-zu-Repo-Betrieb) [email protected] >> remote/origin/[email protected]

  2. Neue Commits in die lokale Niederlassung integrieren

    (Repo-Betrieb innerhalb) 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 den 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 der gitTerminologie ist Schritt 1 git fetch, Schritt 2 git mergeodergit rebase

git pullist git fetchundgit merge


Ich habe auch damit zu kämpfen. Tatsächlich bin ich mit einer Google-Suche genau der gleichen Frage hierher gekommen. Nachdem ich all diese Antworten gelesen hatte, zeichnete ich schließlich ein Bild in meinem Kopf und ich beschloss, dies zu versuchen, indem ich mir den Zustand der 2 Repositories und 1 Sandbox sowie die im Laufe der Zeit durchgeführten Aktionen ansehe, während ich deren Version 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 hat mir geholfen zu verstehen, warum ein Abruf so wichtig ist.


git-pull - Fetch from and merge with another repository or a local branch
SYNOPSIS

git pull   …
DESCRIPTION

Runs git-fetch with the given parameters, and calls git-merge to merge the 
retrieved head(s) into the current branch. With --rebase, calls git-rebase 
instead of git-merge.

Note that you can use . (current directory) as the <repository> to pull 
from the local repository — this is useful when merging local branches 
into the current branch.

Also note that options meant for git-pull itself and underlying git-merge 
must be given before the options meant for git-fetch.

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.


git pull = git fetch + git merge 




git-fetch