Was sind die Unterschiede zw git pull
und git fetch
?
Was ist der Unterschied zwischen „git pull“ und „git fetch“?
Puppe
Mouna Cheikhna
-
Wenn Sie verwenden
pull
Git versucht automatisch zusammenzuführen. Es ist kontextsensitivsodass Git alle gezogenen Commits in den Zweig zusammenführt, an dem Sie gerade arbeiten.pull
führt die Commits automatisch zusammen ohne dass Sie sie zuerst überprüfen können. Wenn Sie Ihre Branches nicht sorgfältig verwalten, können häufig Konflikte auftreten. -
Wenn du
fetch
sammelt Git alle Commits aus dem Zielzweig, die in Ihrem aktuellen Zweig nicht vorhanden sind, und speichert sie in Ihrem lokalen Repository. Aber, sie werden nicht mit Ihrem aktuellen Zweig zusammengeführt. 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 aktuellen Zweig zu integrieren, müssen Sie verwendenmerge
danach.
-
Stimmt, toller Kommentar. Deshalb hasse ich Git-Pull. Wann würde es jemals Sinn machen, ein Revisionstool Codeänderungen für Sie vornehmen zu lassen? Und macht das nicht das Zusammenführen von zwei Dateien? Was ist, wenn diese beiden Bearbeitungen in der Datei physisch getrennt sind, aber LOGISCH unvereinbar sind?
– Lee Dixon
13. Mai 2013 um 18:44 Uhr
-
Ich bin mir nicht sicher, ob ich das richtig verstehe. Lassen Sie mich wissen, ob ich Recht habe: Nehmen wir an, ich habe zwei Zweige, Master und Test. test ist ein Zweig, an dem ich arbeite, um etwas zu experimentieren. Wenn ich git fetch ausführe, wird master mit dem Zielzweig aktualisiert. Wenn ich git pull mache, versucht es, test mit dem Zielzweig zu aktualisieren. Ist das richtig? Wenn nicht, verstehe ich nicht, was “lokales Repository” bedeutet – ich nahm an, dass es meinen lokalen Master bedeutet.
– elexhobby
5. Juni 2013 um 19:15 Uhr
-
@elexhobby kurz gesagt,
git fetch
aktualisiert nur Ihre.git/
Verzeichnis (AKA: lokales Repository) und nichts außerhalb.git/
(AKA: Arbeitsbaum). Es ändert nicht Ihre lokalen Niederlassungen und es berührt sie nichtmaster
entweder. Es berührtremotes/origin/master
obwohl (vglgit branch -avv
). Wenn Sie mehr Fernbedienungen haben, versuchen Sie esgit remote update
. Das ist eingit fetch
für alle Fernbedienungen in einem Befehl.– Tine
17. Juli 2013 um 6:48 Uhr
-
@Tino deiner ist wirklich der wichtigste Punkt. Die Leute wissen vielleicht nicht, dass “entfernte” Zweige tatsächlich als Haufen von Hashes gespeichert werden
.git/refs/remotes/origin/
.– Chris
12. September 2013 um 21:49 Uhr
-
Damit,
fetch
Befehl ist so etwas wie ein “commit from the remote to local”. Rechts?– carloswm85
12. August 2021 um 20:44 Uhr
-
Technisch gesehen sind die lokalen und entfernten Repositories wirklich ein und dasselbe. In Git ist ein Repository a DAG von Commits, die auf ihre Eltern verweisen. Branches sind technisch nichts anderes als aussagekräftige Namen von Commits. Der einzige Unterschied zwischen lokalen und entfernten Zweigen besteht darin, dass entfernten Zweigen das Präfix vorangestellt wird
remoteName/
Git von Grund auf ist sehr gut zu lesen. Sobald Sie verstehen, wie Git funktioniert – und es ist wunderschön einfachwirklich – alles macht einfach Sinn.– Emil Lundberg
14. August 2013 um 9:51 Uhr
Contango
Hier ist Oliver Steeles Bild davon, wie alles zusammenpasst:
Wenn genügend Interesse besteht, könnte ich das Bild aktualisieren, um es hinzuzufügen git clone
und git merge
…
-
Ein aktualisiertes Bild mit
git clone
undgit merge
wäre sehr hilfreich!– MEMark
8. September 2015 um 14:23 Uhr
-
Ja, bitte ergänzen
git merge
– das sollte es deutlich zeigenmerge
Getrennt angerufen ist NICHT dasselbe wie anzurufenpull
dapull
führt nur von Remote zusammen und ignoriert Ihre lokalen Commits in Ihrem lokalen Zweig, der den Remote-Zweig verfolgt, von dem gezogen wird.– JustAMartin
21. Oktober 2015 um 19:57 Uhr
-
Ein Bild sagt mehr als tausend Worte! Ist das aktualisierte Image mit Clone-and-Merge-Datenfluss irgendwo fertig? Irgendein anderer Datenfluss außer dem, was bereits im Diagramm ist?
– Shikhanshu
25. November 2015 um 0:27 Uhr
Kante
Ein Anwendungsfall von git fetch
ist, dass das Folgende Ihnen alle Änderungen im Remote-Zweig seit Ihrem letzten Pull mitteilt … damit Sie vor dem eigentlichen Pull überprüfen können, was Dateien in Ihrem aktuellen Zweig und Ihrer Arbeitskopie ändern könnte.
git fetch
git diff ...origin
Sehen: https://git-scm.com/docs/git-diff bezüglich Doppel- und Dreifachpunkt-Syntax im diff-Befehl
-
Ein aktualisiertes Bild mit
git clone
undgit merge
wäre sehr hilfreich!– MEMark
8. September 2015 um 14:23 Uhr
-
Ja, bitte ergänzen
git merge
– das sollte es deutlich zeigenmerge
Getrennt angerufen ist NICHT dasselbe wie anzurufenpull
dapull
führt nur von Remote zusammen und ignoriert Ihre lokalen Commits in Ihrem lokalen Zweig, der den Remote-Zweig verfolgt, von dem gezogen wird.– JustAMartin
21. Oktober 2015 um 19:57 Uhr
-
Ein Bild sagt mehr als tausend Worte! Ist das aktualisierte Image mit Clone-and-Merge-Datenfluss irgendwo fertig? Irgendein anderer Datenfluss außer dem, was bereits im Diagramm ist?
– Shikhanshu
25. November 2015 um 0:27 Uhr
orte
Es hat mich ein wenig gekostet, zu verstehen, was der Unterschied war, aber dies ist eine einfache Erklärung. master
in Ihrem localhost ist ein Zweig.
Wenn Sie ein Repository klonen, holen Sie das gesamte Repository auf Ihren lokalen Host. Das bedeutet, dass Sie zu diesem Zeitpunkt einen Ursprungs-/Hauptzeiger haben HEAD
und Meister, der auf dasselbe zeigt HEAD
.
Wenn Sie mit der Arbeit beginnen und Commits durchführen, rücken Sie den Master-Zeiger vor HEAD
+ Ihre Zusagen. Aber der Origin/Master-Zeiger zeigt immer noch auf das, was er war, als Sie geklont haben.
Der Unterschied wird also sein:
- Wenn Sie eine
git fetch
Es werden einfach alle Änderungen im Remote-Repository abgerufen (GitHub) und bewegen Sie den Ursprungs-/Hauptzeiger aufHEAD
. In der Zwischenzeit wird Ihr lokaler Zweigstellenleiter darauf hinweisen, wo er ist. - Wenn Sie eine
git pull
wird es im Grunde genommen (wie zuvor erklärt) alle neuen Änderungen in Ihrem Master-Zweig abrufen und zusammenführen und den Zeiger auf verschiebenHEAD
.
-
origin/master ist eine lokale Verzweigung, die eine KOPIE von master auf origin ist. Beim Abrufen aktualisieren Sie local:/origin/master. Wenn Sie einmal wirklich geglaubt haben, dass alles in Git ein Branch ist, macht dies sehr viel Sinn und ist eine sehr leistungsfähige Methode, um verschiedene Changesets zu verwalten, schnelle lokale Branches zu erstellen, Merge und Rebase zu erstellen und im Allgemeinen viel Wert aus dem billigen Branching zu ziehen Modell.
– cam8001
28. Mai 2013 um 16:00 Uhr
Ich habe diesen gut geschriebenen Artikel über Git-Fetch und Git-Pull gefunden, der es wert ist, gelesen zu werden: longair.net/blog/2009/04/16/git-fetch-and-merge
– Marcos Oliveira
16. September 2010 um 6:57 Uhr
Unser alternativer Ansatz ist geworden
git fetch; git reset --hard origin/master
als Teil unseres Workflows. Es bläst lokale Änderungen weg, hält Sie mit dem Master auf dem Laufenden, ABER stellt sicher, dass Sie nicht einfach neue Änderungen über aktuelle Änderungen ziehen und ein Chaos anrichten. Wir verwenden es seit einiger Zeit und es fühlt sich in der Praxis im Grunde viel sicherer an. Stellen Sie nur sicher, dass Sie zuerst alle laufenden Arbeiten hinzufügen/festschreiben/verstauen!– Michael Durrant
4. Mai 2014 um 14:32 Uhr
Stellen Sie sicher, dass Sie wissen, wie Sie Git Stash richtig verwenden. Wenn Sie nach „Pull“ und „Fetch“ fragen, muss „Stash“ vielleicht auch erklärt werden …
– Heinrich Heleine
9. Dezember 2014 um 20:09 Uhr
Viele Leute, die von Mercurial kommen, verwenden weiterhin “git pull” und denken, es sei ein Äquivalent für “hg pull”. Was es nicht ist. Gits Äquivalent zu „hg pull“ ist „git fetch“.
– Serge Schultz
29. Juni 2015 um 10:15 Uhr
Ein sehr gut geschriebener Artikel über git pull vs fetch freecodecamp.org/news/git-fetch-vs-pull
– Ich bin ein Anfänger
19. Dezember 2021 um 19:58 Uhr