Git: pull vs. fetch→pull [duplicate]

Lesezeit: 4 Minuten

Auf diese Frage konnte ich nie eine klare Antwort bekommen.

Seit langem und auf Anraten eines Kollegen mache ich das:

git fetch origin
git pull origin <mybranch>

Das wurde mir gesagt (und ich habe es gesehen). git pull verhält sich nicht gleich, wenn man es nicht zuerst tut git fetch. Sie erhalten keine Remote-Änderungen.

Aber alles, was ich online sehe, ist das git pull ist das Äquivalent von git fetch gefolgt von git merge. Wenn das wahr wäre, git pull würde beinhalten git fetchund ich bräuchte keine explizite git fetch erstes richtig? Aber das scheint nicht der Fall zu sein.

Was ich also suche, ist eine explizite Dokumentation, die das beobachtete Verhalten von beschreibt git pull. (Ich weiß, dass ich wahrscheinlich auch viele Ratschläge bekommen werde, zu denen ich wechseln kann git fetchgit merge; das ist auch in Ordnung, aber ich interessiere mich wirklich dafür git pull.)

  • amtliche Dokumentation: Integriert Änderungen aus einem Remote-Repository in den aktuellen Zweig. In seinem Standardmodus git pull ist eine Abkürzung für git fetch gefolgt von git merge FETCH_HEAD.

    – Benutzer4003407

    20. Mai 2016 um 16:41 Uhr

  • Fetch ist gut, um neue Änderungen zu sehen, bevor sie auf Ihr lokales Repository angewendet werden.

    – SeinopSys

    20. Mai 2016 um 16:43 Uhr

Wir sollten dies wahrscheinlich als Duplikat schließen, aber bevor das passiert, lassen Sie mich sehen, ob ich das hineinquetschen kann.

Während git pull Ja wirklich ist git fetch gefolgt von git merge (oder git rebase), das präzise Unterschied liegt darin wie git pull läuft git fetch.

Speziell:

$ git pull

oder:

$ git pull remote-name branch-name

(oder diverse ähnliche Varianten) läuft, nicht glatt git fetchnicht git fetch remote-nameaber git fetch remote-name branch-name.

Das hat weniger Unterschied, da Git-Version 1.8.4als vor dieser Version:

  • git fetch origin master nicht wie git fetch origin oder git fetch
    nicht aktualisiert refs/remotes/origin/master; Dies war eine frühe Entwurfsentscheidung, um die Aktualisierung von Remote-Tracking-Branches vorhersehbar zu halten, aber in der Praxis stellt sich heraus, dass die Leute es bequemer finden, sie bei jeder Gelegenheit opportunistisch zu aktualisieren, und wir haben sie aktualisiert, wenn wir sie ausführen git push was sowieso schon die ursprüngliche “Berechenbarkeit” bricht.

Mit anderen Worten, wenn git pull beschließt zu laufen git fetch origin masterdies wird aktualisiert origin/master in Ihrem Repository – aber nur, wenn Sie keine alten Versionen von Git ausführen B. solche, die in bestimmten unbenannten Linux-Distributionen enthalten sind.

Wenn du läufst git fetch originSie erhalten alle Remote-Tracking-Zweige aktualisiert (vorausgesetzt, Sie haben eine vernünftige Konfiguration, die selbst in diesen alten Versionen von Git die Standardeinstellung ist). Wenn du läufst git fetch origin masterbekommst du nur origin/master aktualisiert, und wieder nur, wenn Ihr Git nicht zu lächerlich veraltet ist. Seit git pull die Vier-Wort-Variante ausführt, aktualisiert sie nur einen oder gar keinen Remote-Tracking-Zweig.

Mir wurde gesagt (und ich habe gesehen), dass sich git pull nicht auf die gleiche Weise verhält, wenn Sie nicht zuerst git fetch ausführen. Sie erhalten keine Remote-Änderungen.

Normalerweise stimmt das nicht, und git pull zieht den Status von der Fernbedienung.

Aber alles, was ich online sehe, ist, dass git pull das Äquivalent von git fetch gefolgt von git merge ist. Wenn das wahr wäre,

es ist!

Unter Berufung auf die Handbuchseite von git-pull:

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

Ich denke, das erledigt sich.

Was ich also suche, ist eine explizite Dokumentation

$ git help pull

  • Ja, sehen Sie, aber es tut anders verhalten. Ich kann es den ganzen Tag duplizieren. Das ist es, was mich verwirrt.

    – Johannes Alexander

    20. Mai 2016 um 17:04 Uhr


  • wie verhält es sich anders?

    – Gregor

    20. Mai 2016 um 17:14 Uhr

  • @JohnAlexander Wie sieht dein Tracking-Setup aus? git branch -avv Wird dir zeigen. Vielleicht sehen Ihre Tracking-Beziehungen nicht so aus, wie die Leute hier erwarten.

    – Dan Lowe

    20. Mai 2016 um 19:23 Uhr

git pull ist ein get fetch gefolgt von einem git merge. (oder Sie können stattdessen mit der Option –rebase rebasen). Also nein, du musst keinen ‘git fetch’ vor einem ‘git pull’ machen

Geben Sie „git help fetch“ und „git help pull“ für Beschreibungen ein

git fetch geht zum benannten Repository, ruft das Objekt ab, auf das verwiesen wird (normalerweise ein Commit), ruft es und alle seine abhängigen Objekte ab und speichert es im benannten Remote-Tracking-Zweig. Sie könnten dann von dort aus zusammenführen oder rebasen. ‘git merge origin/master’ oder Sie können es einfach mit ‘git checkout origin/master’ anzeigen

1176700cookie-checkGit: pull vs. fetch→pull [duplicate]

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy