2012-08-06 8 views
5

Kann jemand bitte ein einfaches Beispiel dafür geben, was einen Git-Push zu einem zentralen Repo zum Fehlschlagen bringen würde, weil ein schneller Vorlauf nicht stattfinden konnte? Wie müsste der lokale Repo gegenüber dem Staat des zentralen Repo aussehen, damit dies geschieht? Wirklich Probleme bei der Visualisierung dieser ...Was bedeutet es, dass ein Git Push nicht schnell fusioniert werden kann?

+0

Ausgezeichnete Frage! Viele Leute verstehen das nicht, aber die meisten Fragen, die ich dabei fand, sind nicht so gut geschrieben. – erikbwork

Antwort

11

Ich nehme an, Sie sehen dieses Problem:

! [rejected]  master -> master (non-fast-forward) 
error: failed to push some refs to '/Users/mayoff/t/test/central' 
To prevent you from losing history, non-fast-forward updates were rejected 
Merge the remote changes (e.g. 'git pull') before pushing again. See the 
'Note about fast-forwards' section of 'git push --help' for details. 

Hier ist, wie die „Nicht-vorspulen Updates abgelehnt wurden“ Problem passiert.

Angenommen, Alice und Bob arbeiten an einem Projekt. Sie verfügen jeweils über ein Repository, und es gibt ein zentrales Repository, an das sie beide herangehen und von dem sie ziehen. Zunächst sehen die drei Repositorys wie folgt aus:

initial synchronized repos

Jetzt Alice und Bob beide etwas arbeiten. Jeder begeht eine andere Veränderung in ihrem lokalen Repository:

private repos have new commits

Als nächstes Alice schiebt ihren Wechsel zum zentralen Repo:

central repo updated by Alice

Als nächstes Bob versucht zu schieben. Der Master-Zweig des zentralen Repos zeigt auf Commit 3. Bobs Push versucht, ihn zu aktualisieren, um auf Commit 4 zu zeigen. Da Commit 4 Commit 3 nicht als Vorgänger hat, ist eine Zusammenführung erforderlich, aber git push führt keine echten Zusammenführungen durch. Es macht nur "Schnellvorlauf", wo der neue Meister den alten Meister als Vorfahr hat. Also bekommt Bob den Fehler, weil er versucht, etwas zu drücken, das eine echte Zusammenführung erfordert, keinen Schnellvorlauf.

erfolgreich zu drücken, hat Bob zunächst die neue von der zentralen Repo begehen zu holen:

Bob has fetched Alice's commit

und er hat seine Änderungen zu fusionieren (commit # 4) mit Alices Änderungen (commit # 3) eine neue commit, dass die Schaffung sowohl verpflichtet als Vorfahren:

Bob has merged the commits

Die Abruf- und Zusammenführen kann in zwei Befehle (git fetch gefolgt vongeschehen) oder in einem Befehl (git pull).

Jetzt kann Bob erfolgreich pushen, weil der zentrale Repo sieht, dass der neue Master den alten Master als Vorfahr hat.

Bob pushed the merge

Beachten Sie, dass jetzt Alice Bobs Commits fehlt. Wenn sie mehr Commits zu ihrem Repo macht und versucht, zu pushen, bevor sie aus dem zentralen Repo zieht, erhält sie den Non-Fast-Forward-Fehler, und sie muss ihn holen und zusammenführen, um ihn zu reparieren, genau wie Bob.

+0

Ich habe gerade gemerkt, dass alle meine Pfeile in die falsche Richtung zeigen. Naja.Hoffentlich ist es klar genug. –

+0

Nun, jetzt zeigen sie die Entwicklung in der Zeit und nicht den Git Baum. Das ist auch nicht so schlimm. – erikbwork

+0

Konsistenz ist der Schlüssel. und in Richtung der fortschreitenden Zeit zeigen kann tatsächlich für einige Leute bequemer sein. – araqnid

0

Machen Sie einfach einen Commit auf dem zentralen Repo auf dem gleichen Zweig, ohne zu Ihrem lokalen zu ziehen. Dann lokal committen und versuchen zu drücken.