Was sind die Unterschiede zwischen git pull y git fetch ?
Vereinfacht ausgedrückt, git pull macht eine git fetch gefolgt von einer git merge .
Sie können eine git fetch jederzeit, um Ihre Remote-Tracking-Zweige zu aktualisieren unter refs/remotes/<remote>/ . Dieser Vorgang ändert niemals eine Ihrer eigenen lokalen Niederlassungen unter refs/heads und kann sicher durchgeführt werden, ohne die Arbeitskopie zu verändern. Ich habe sogar von Leuten gehört, die git fetch regelmäßig in einem Cron-Job im Hintergrund ausführen (obwohl ich das nicht empfehlen würde).
A git pull ist das, was Sie tun würden, um einen lokalen Zweig auf den neuesten Stand mit seiner entfernten Version zu bringen, während Sie auch Ihre anderen entfernten Zweige auf den neuesten Stand bringen.
Aus der Git-Dokumentation für git pull :
Im Standardmodus,
git pullist die Kurzform fürgit fetchgefolgt vongit merge FETCH_HEAD.
"Ein "git pull" ist das, was Sie tun würden, um Ihr Repository auf den neuesten Stand zu bringen" <- wird die Aktualisierung des Repository nicht bereits durch fetch durchgeführt? meinen Sie nicht, dass es Ihre lokalen Zweige mit den entfernten Zweigen auf den neuesten Stand bringt? Zum Zusammenführen: Es führt die entfernten Zweige mit deinen lokalen Kopien dieser Zweige zusammen, oder was genau wird hier zusammengeführt?
@Albert: Ja, das ist seltsam formuliert. git pull geht immer in die aktuelle Branche . Sie wählen also den Zweig aus, den Sie ziehen wollen von und zieht es in den aktuellen Zweig. Die von Zweig kann lokal oder entfernt sein; es kann sogar ein entfernter Zweig sein, der kein registrierter git remote (das heißt, Sie übergeben eine URL auf der git pull Befehlszeile).
Ist ein "git push" auch ein "git fetch" (in die andere Richtung), gefolgt von einem "git merge"?
Wenn Sie pull versucht Git, automatisch zusammenzuführen. Sie ist kontextsensitiv so dass Git alle gezogenen Commits in den Zweig zusammenführt, an dem Sie gerade arbeiten. pull führt die Übertragungen automatisch zusammen ohne Sie vorher überprüfen zu lassen . Wenn Sie Ihre Zweigstellen nicht sorgfältig verwalten, kann es häufig zu Konflikten kommen.
Wenn Sie fetch sammelt Git alle Commits aus dem Ziel-Branch, die nicht in Ihrem aktuellen Branch vorhanden sind, und speichert sie in Ihrem lokalen Repository . Allerdings, Sie werden nicht mit dem 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 kaputt gehen könnte, wenn Sie Ihre Dateien aktualisieren. Um die Übertragungen in Ihren aktuellen Zweig zu integrieren, müssen Sie merge danach.
Einverstanden, toller Kommentar. Deshalb hasse ich auch Git Pull. Wann würde es jemals Sinn machen, ein Revisionswerkzeug Codeänderungen für Sie vornehmen zu lassen? Und ist es nicht genau das, was das Zusammenführen zweier Dateien bewirkt? Was ist, wenn diese beiden Änderungen physisch in der Datei getrennt sind, aber LOGISCH nicht übereinstimmen?
Ich bin mir nicht sicher, ob ich das richtig verstanden habe. Lassen Sie mich wissen, ob ich richtig liege: Sagen wir, ich habe zwei Zweige, master und test. test ist ein Zweig, an dem ich arbeite, um etwas zu testen. Wenn ich git fetch ausführe, wird master mit dem Zielzweig aktualisiert. Wenn ich git pull ausführe, versucht es, test mit dem Zielzweig zu aktualisieren. Ist das richtig? Falls nicht, verstehe ich wohl nicht, was "lokales Repository" bedeutet - ich nahm an, dass damit mein lokaler Master gemeint ist.
@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 Zweige und berührt nicht master entweder. Es berührt remotes/origin/master allerdings (siehe git branch -avv ). Wenn Sie mehrere Fernbedienungen haben, versuchen Sie git remote update . Dies ist eine git fetch für alle Fernbedienungen in einem einzigen Befehl.
Es ist wichtig, die Designphilosophie von Git mit der Philosophie eines traditionelleren Versionskontrollwerkzeugs wie SVN zu vergleichen.
Subversion wurde mit einem Client/Server-Modell entwickelt und gebaut. Es gibt ein einziges Repository, das den Server darstellt, und mehrere Clients können Code vom Server abrufen, daran arbeiten und ihn dann an den Server zurückgeben. Es wird davon ausgegangen, dass der Client immer den Server kontaktieren kann, wenn er eine Operation durchführen muss.
Git wurde entwickelt, um ein eher verteiltes Modell zu unterstützen, bei dem kein zentrales Repository benötigt wird (obwohl Sie natürlich eines verwenden können, wenn Sie möchten). Außerdem wurde Git so konzipiert, dass der Client und der "Server" nicht zur gleichen Zeit online sein müssen. Git wurde so konzipiert, dass Leute mit einer unzuverlässigen Verbindung Code sogar per E-Mail austauschen können. Es ist möglich, völlig unverbunden zu arbeiten und eine CD zu brennen, um Code über Git auszutauschen.
Um dieses Modell zu unterstützen, verwaltet Git ein lokales Repository mit Ihrem Code und ein zusätzliches lokales Repository, das den Zustand des entfernten Repositorys widerspiegelt. Indem eine Kopie des entfernten Repositorys lokal gehalten wird, kann Git die erforderlichen Änderungen auch dann ermitteln, wenn das entfernte Repository nicht erreichbar ist. Wenn Sie die Änderungen später an eine andere Person senden müssen, kann Git sie als eine Reihe von Änderungen von einem Zeitpunkt aus übertragen, der dem entfernten Repository bekannt ist.
git fetch ist der Befehl, der sagt: "Bringe meine lokale Kopie des entfernten Repositorys auf den neuesten Stand".
git pull sagt: "Bringe die Änderungen im entfernten Repository dorthin, wo ich meinen eigenen Code aufbewahre."
Normalerweise git pull tut dies, indem es eine git fetch um die lokale Kopie des entfernten Repositorys auf den neuesten Stand zu bringen, und dann die Änderungen in Ihr eigenes Code-Repository und möglicherweise Ihre Arbeitskopie einzubinden.
Es gilt zu bedenken, dass es oft mindestens eine drei Exemplare eines Projekts auf Ihrer Workstation. Eine Kopie ist Ihr eigenes Repository mit Ihrer eigenen Commit-Historie. Die zweite Kopie ist Ihre Arbeitskopie, in der Sie das Projekt bearbeiten und erstellen. Die dritte Kopie ist Ihre lokale "gecachte" Kopie eines entfernten Repositorys.
Technisch gesehen sind die lokalen und entfernten Repositories ein und dasselbe. In Git ist ein Repository ein DAG von Übertragungen, die auf ihre Eltern verweisen. Branches sind technisch gesehen nichts anderes als aussagekräftige Namen von Commits. Der einzige Unterschied zwischen lokalen und entfernten Zweigen ist, dass entfernte Zweige mit dem Präfix remoteName/ Git von Grund auf ist eine sehr gute Lektüre. Wenn man einmal verstanden hat, wie Git funktioniert - und es ist wunderschön einfach wirklich - alles macht einfach Sinn.
Falsch. Ein Repository enthält keine Kopie Ihres Arbeitsbaums. Ein Repository ist eine Liste von Änderungen. Es gibt also nur eine einzige Instanz eines Projekts auf einer Workstation, es sei denn, Sie legen es explizit mit cp -R ab.
Hier ist Oliver Steeles Vorstellung davon, wie alles zusammenpasst :
Wenn es genügend Interesse gibt, könnte ich das Bild aktualisieren und Folgendes hinzufügen git clone y git merge ...
Ja, bitte hinzufügen git merge - es sollte deutlich zeigen, dass merge separat aufgerufen wird, ist NICHT dasselbe wie der Aufruf von pull denn pull wird nur vom entfernten Zweig zusammengeführt und ignoriert Ihre lokalen Commits in Ihrem lokalen Zweig, der den entfernten Zweig, von dem gezogen wird, verfolgt.
Ein Bild sagt mehr als tausend Worte! Steht das aktualisierte Bild mit dem Datenfluss für das Klonen und Zusammenführen irgendwo bereit? Gibt es einen anderen Datenfluss als den, der bereits im Diagramm enthalten ist?
Ein Anwendungsfall von git fetch ist, dass das Folgende Sie über alle Änderungen im entfernten Zweig seit Ihrem letzten Pull informiert... so können Sie überprüfen, bevor Sie einen tatsächlichen Pull durchführen, der Dateien in Ihrem aktuellen Zweig und Ihrer Arbeitskopie ändern könnte.
git fetch
git diff ...originSiehe: https://git-scm.com/docs/git-diff zur Doppel- und Dreifach-Punkt-Syntax im diff-Befehl
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
439 Stimmen
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
70 Stimmen
Unser alternativer Ansatz hat sich
git fetch; git reset --hard origin/masterals Teil unseres Arbeitsablaufs. Es blendet lokale Änderungen aus, hält Sie mit dem Master auf dem Laufenden, stellt aber sicher, dass Sie nicht einfach neue Änderungen über die aktuellen Änderungen ziehen und ein Durcheinander verursachen. Wir verwenden es schon eine Weile und es fühlt sich in der Praxis viel sicherer an. Stellen Sie nur sicher, dass Sie alle laufenden Arbeiten zuerst hinzufügen/übertragen/verstecken!40 Stimmen
Vergewissern Sie sich, dass Sie wissen, wie man git stash richtig verwendet. Wenn du nach "pull" und "fetch" fragst, dann ist vielleicht auch "stash" erklärungsbedürftig...
49 Stimmen
Viele Leute, die von Mercurial kommen, benutzen "git pull", weil sie denken, es sei ein Äquivalent für "hg pull". Das ist es aber nicht. Git's Äquivalent zu "hg pull" ist "git fetch".
0 Stimmen
Ein sehr gut geschriebener Artikel über git pull vs fetch freecodecamp.org/news/git-fetch-vs-pull
1 Stimmen
Git pull zieht aus einem entfernten Zweig und führt ihn zusammen. git fetch holt nur aus dem entfernten Zweig, führt ihn aber nicht zusammen.
0 Stimmen
Kurze Antwort | git fetch - Sie können die Dateien einsehen, die nach Ihrem letzten Pull übertragen wurden, ohne diese Codes zusammenzuführen. | git pull - Holen Sie sich die Änderungen an Ihrer Codebasis. Es erfolgt ein automatisches Zusammenführen mit Ihrer Codebasis.