wake-up-neo.com

Wie kann ich "Git-Fetch" und "Git-Merge" aus einem Remote-Tracking-Zweig ausführen (wie "Git-Pull")?

Ich habe einige Remote-Tracking-Verzweigungen in git eingerichtet, kann sie jedoch anscheinend nie in die lokale Verzweigung einbinden, nachdem ich sie mit 'git fetch' aktualisiert habe.

Angenommen, ich habe eine entfernte Verzweigung mit dem Namen "eine andere Verzweigung". Ich habe das lokal als Tracking-Zweig mit eingerichtet

git branch --track an-other-branch Origin/an-other-branch

So weit, ist es gut. Wenn dieser Zweig jedoch aktualisiert wird (normalerweise, indem ich den Computer verschiebe und von diesem Computer ein Commit durchführe) und ich ihn auf dem ursprünglichen Computer aktualisieren möchte, treten Probleme beim Abrufen/Zusammenführen auf:

git fetch Origin an-other-branch
git merge Origin/an-other-branch

Immer wenn ich das tue, erhalte ich die Nachricht "Bereits auf dem neuesten Stand" und nichts geht ineinander über.

A

git pull Origin an-other-branch

aktualisiert es immer so, wie Sie es erwarten würden.

Auch Lauf Git Diff

git diff Origin/an-other-branch

zeigt, dass es Unterschiede gibt, also denke ich, dass meine Syntax falsch ist.

Was mache ich falsch?

EDIT [2010-04-09]: Ich habe ein paar Mal nachgesehen und bin definitiv nicht in einem anderen Zweig. Sollte mein 'Git Fetch' gefolgt von einem 'Git Merge' (wie oben gezeigt) genau dasselbe tun wie ein Git Pull? Ich erhalte einen Workflow, der die Ergebnisse eines Git-Status usw. anzeigt.

111
kaybenleroll

Sie holen keine Verzweigung, Sie holen eine ganze Fernbedienung:

git fetch Origin
git merge Origin/an-other-branch
168
Gareth

Auswahl nur eines Zweigs: fetch/merge vs.pull

Häufig wird empfohlen, "Abrufen" von "Zusammenführen" zu trennen. Sie sagen stattdessen:

    git pull remoteR branchB

mach das:

    git fetch remoteR
    git merge remoteR branchB

Was sie nicht erwähnen ist, dass ein solcher Abrufbefehl tatsächlich all Zweige vom entfernten Repository abruft, was not ist, was dieser Abrufbefehl bewirkt. Wenn Sie Tausende von Zweigen im Remote-Repository haben, aber nicht alle sehen möchten, können Sie den folgenden undurchsichtigen Befehl ausführen:

    git fetch remoteR refs/heads/branchB:refs/remotes/remoteR/branchB
    git branch -a  # to verify
    git branch -t branchB remoteR/branchB

Natürlich ist das lächerlich schwer zu merken. Wenn Sie also wirklich vermeiden möchten, alle Zweige abzurufen, ist es besser, Ihr .git/config wie in ProGit beschrieben.

Huh?

Die beste Erklärung dafür finden Sie in Kapitel 9-5 von ProGit, Git Internals - The Refspec ( oder via github ). Das ist erstaunlich schwer über Google zu finden.

Zunächst müssen wir einige Begriffe klären. Bei der Fernverfolgung von Zweigen sind in der Regel drei verschiedene Zweige zu beachten:

  1. Der Zweig auf dem Remote-Repo: refs/heads/branchB im anderen Repo
  2. Ihr Fernverfolgungszweig: refs/remotes/remoteR/branchB in your repo
  3. Ihre eigene Niederlassung: refs/heads/branchB inside your repo

Remote-Tracking-Zweige (in refs/remotes) sind schreibgeschützt. Sie ändern diese nicht direkt. Sie ändern Ihre eigene Niederlassung und drücken dann auf die entsprechende Niederlassung am Remote-Repository. Das Ergebnis spiegelt sich nicht in Ihrem refs/remotes erst nach einem entsprechenden ziehen oder holen. Diese Unterscheidung war aus den Git-Manpages schwer zu verstehen, vor allem, weil die örtliche Niederlassung (refs/heads/branchB) soll den Fernverfolgungszweig "verfolgen", wenn .git/config definiert branch.branchB.remote = remoteR.

Stellen Sie sich 'refs' als C++ - Zeiger vor. Physikalisch handelt es sich um Dateien, die SHA-Digests enthalten, aber im Grunde sind sie nur Zeiger auf den Commit-Baum. git fetch fügt Ihrem Commit-Baum viele Knoten hinzu, aber wie git entscheidet, welche Zeiger verschoben werden sollen, ist etwas kompliziert.

Wie in eine andere Antwort erwähnt, auch nicht

    git pull remoteR branchB

noch

    git fetch remoteR branchB

würde bewegen refs/remotes/branches/branchB, und letzteres kann sich sicherlich nicht bewegen refs/heads/branchB. Beide bewegen sich jedoch FETCH_HEAD. (Sie können cat jede dieser Dateien in .git/ um zu sehen, wann sie sich ändern.) Und git merge bezieht sich auf FETCH_HEAD, während MERGE_ORIG, etc.

67
cdunn2001

Sind Sie sicher, dass Sie auf dem lokalen an-other-branch wann fusionierst du?

git fetch Origin an-other-branch
git checkout an-other-branch
git merge Origin/an-other-branch

Die andere Erklärung :

alle Änderungen der Zweigstelle, die Sie zusammenführen möchten, wurden bereits mit der Zweigstelle zusammengeführt, in der Sie sich gerade befinden.
Konkret bedeutet dies, dass der Zweig, den Sie zusammenführen möchten, ein übergeordneter Zweig Ihres aktuellen Zweigs ist

wenn Sie dem Remote-Repo um ein Commit voraus sind, ist das Remote-Repo nicht mehr aktuell, sondern Sie.

Aber in deinem Fall, wenn git pull funktioniert, das bedeutet nur, dass Sie nicht auf dem richtigen Ast sind.

9
VonC

Git Pull ist eigentlich ein Combo-Tool: Es führt Git-Fetch (Abrufen der Änderungen) und Git-Merge (Zusammenführen der Änderungen mit Ihrer aktuellen Kopie) aus.

Sind Sie sicher, dass Sie sich in der richtigen Branche befinden?

3
RDL

dies sind die Befehle:

git fetch Origin
git merge Origin/somebranch somebranch

wenn Sie dies in der zweiten Zeile tun:

git merge Origin somebranch

es wird versucht, den lokalen Master in Ihrem aktuellen Zweig zusammenzuführen.

Die Frage, wie ich es verstanden habe, war, dass Sie bereits lokal abgerufen wurden und nun Ihren Zweig mit dem neuesten des Zweigs dasselbe zusammenführen möchten.

1
user1524957