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 .

Hier ist Oliver Steeles Image, wie alles zusammenpasst :

Wenn genügend Interesse besteht, könnte ich das Bild aktualisieren, um git clone und git merge hinzuzufügen ...

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