2012-04-08 12 views
2

Wenn ich einen Git schieben, sehe ich 3 Zweige beteiligt. 1) Der lokale Zweig, an dem ich arbeite, sage 'foo1' 2) den lokalen Remote-Tracking-Zweig 'origin/foo2' (der immer nach dem Drücken/Ziehen denselben Commit wie der entfernte foo3 hat) 3) 'foo3' in das entfernte Repo. Normalerweise würden sie alle foo heißen, aber ich möchte andere Namen haben, damit ich Git verstehen und diese Frage hier stellen kann. Ich verstehe nicht, wo ich foo2 angeben kann. Wenn ichGeben Sie den 'Ursprung/Master' Teil in einem Git drücken

git push origin foo1:foo3 

Und das in meinem .git/config mit

[branch "master"] 
remote = origin 
merge = refs/remotes/origin/foo2 

Punkt 1 und 3 sind in Ordnung, aber ich habe nicht einen Ursprung/foo2 in meinem lokalen Repo. Was vermisse ich? Oder ist die Antwort, dass meine Remote-Tracking-Filialen sind immer benannt genau die gleiche Art und Weise wie die Fernbedienungen - das wäre in Ordnung für mich - ich will nur Git richtig zu verstehen.

Das git-push Handbuch spricht auch nur von zwei Referenzen (refspec src und dst), Punkt 1 und 3, in meinem Beispiel. Wo wird das Handbuch nach der Aktualisierung des dst-Zweigs im Remote-Repo aktualisiert, wird auch die lokale Remote-Tracking-Referenz aktualisiert?

+0

@ VonCs Antwort ist richtig (natürlich :-)). Ich vermute, das grundlegende Problem hier ist, dass Sie über die offensichtliche Symmetrie zwischen "Push" und "Pull" stolpern. Es ist eine falsche Symmetrie. Das Gegenteil von 'push' ist nicht' pull', es ist 'fetch'. (Auch dann sind sie nicht genau symmetrisch.) Behalte das im Hinterkopf und alles sollte mehr Sinn ergeben. – torek

Antwort

1

Sie sehen drei Zweige auf Git Push nicht. Nur zwei

Die foo2 Sie beschreiben ist für git pull (GIT + git merge fetch) oder git rebase:
(von git config)

branch.<name>.merge 

definiert zusammen mit branch.<name>.remote der stromaufwärtige Zweig für der angegebene Zweig.
Er teilt git fetch/git pull/git rebase mit, welche Verzweigung zu fusionieren ist und kann auch den Git-Push beeinflussen (siehe push.default).
Wenn in der Verzweigung <name>10, sagt es git holen die Standard refspec für die Zusammenführung in FETCH_HEAD markiert werden. Der Wert wird wie der entfernte Teil einer refspec behandelt und muss mit einem ref übereinstimmen, der von der durch "branch.<name>.remote" angegebenen Gegenstelle abgerufen wird.

Die merge Informationen werden von git pull (die auf den ersten Anrufe git fetch), die zum Zusammenführen Default-Zweig nachzuschlagen.
Ohne diese Option wird git pull standardmäßig die erste refspec abgerufen zusammengeführt.
Geben Sie mehrere Werte an, um eine Octopus-Zusammenführung zu erhalten.

anzumerken, dass mit nach git1.7.10 könnte die Standarddruckpolitik matching zu upstream ändern (siehe "What is the result of git push origin?"), was bedeutet, einen branch.<name>.mergestromauf Zweig definieren (in Abwesenheit von branch.<name>.remote) Es könnte dann standardmäßig für eine git push verwendet werden.

0

Sie haben Recht, der Remote-Tracking-Zweig hat den gleichen Namen wie der Zweig im Remote-Repo. Es wäre sonst etwas verwirrend!

So stellt origin/foo3 einfach Zweig foo3 in der Fernbedienung origin. Es wird korrekt mit der Fernbedienung synchronisiert, nachdem git fetch ausgeführt wurde.Beachten Sie, dass bei der Ausführung von git pull tatsächlich git fetch ; git merge ausgeführt wird.

Wenn Sie git push origin foo1:foo3 ausführen, drücken Sie Ihren lokalen Zweig foo1 auf den Remote-Zweig origin/foo3. In diesem Fall ist es nicht sinnvoll, einen Zweig foo2 anzugeben.

+0

Siehe, ich kann 'git checkout -b foo1; git pull Herkunft foo3: Fernbedienungen/Herkunft/foo2'. Also im Pull-Szenario habe ich jetzt genau die 3 Zweige in meiner Frage beschrieben. Hier ist es möglich, jede der drei Zweige spezifisch zu spezifizieren. Alle drei können verschiedene Namen haben, auch wenn es keinen Sinn ergibt. Aber irgendwie umgekehrt, kann nur foo1 und foo3 beeinflussen ('git push ursprung foo1: foo3'), aber nicht mehr foo2, und das verwirrt mich total; Ich verstehe diese Asymmetrie nicht. Ich bin sicher, ich vermisse etwas. –