it-swarm.com.de

master Branch und "Origin/Master" haben sich auseinandergezogen, wie "Zweige abwehren"?

Irgendwie sind mein Meister und mein Herkunfts-/Meisterzweig auseinandergegangen. Ich möchte eigentlich nicht, dass sie auseinander gehen. Wie kann ich diese Unterschiede sehen und "zusammenführen"?

794
Frank

Sie können die Unterschiede überprüfen mit einem:

git log HEAD..Origin/master

vor ziehen (fetch + merge) (siehe auch "Wie kriegt man git immer von einem bestimmten Zweig?" )


Wenn Sie eine Nachricht haben wie:

Msgstr "Ihr Zweig und" Ursprung/Meister "sind auseinandergegangen, # und haben jeweils 1 und 1 verschiedene Commits."

, überprüfen Sie, ob Sie müssen Origin aktualisieren. Wenn Origin auf dem neuesten Stand ist, wurden einige Commits aus einem anderen Repo auf Origin verschoben, während Sie lokal eigene Commits vorgenommen haben.

... o ---- o ---- A ---- B  Origin/master (upstream work)
                   \
                    C  master (your work)

Sie basierten Commit C auf Commit A, weil dies die letzte Arbeit war, die Sie zu diesem Zeitpunkt vom Upstream abgerufen hatten.

Bevor Sie jedoch versucht haben, zu Origin zurückzukehren, hat jemand anderes Commit B gedrückt.
Die Entwicklungsgeschichte ist in unterschiedliche Pfade aufgeteilt. 

Sie können dann zusammenführen oder rebasieren. Siehe Pro Git: Git Branching - Rebasing für Details.

Zusammenführen

Verwenden Sie den Befehl git merge:

$ git merge Origin/master

Dies weist Git an, die Änderungen von Origin/master in Ihre Arbeit zu integrieren und ein Zusammenführungs-Commit zu erstellen.
Das Diagramm der Geschichte sieht nun so aus: 

... o ---- o ---- A ---- B  Origin/master (upstream work)
                   \      \
                    C ---- M  master (your work)

Die neue Zusammenführung, Commit M, hat zwei Elternteile, von denen jedes einen Entwicklungspfad darstellt, der zu dem in diesem Commit gespeicherten Inhalt geführt hat.

Beachten Sie, dass die Historie hinter M jetzt nicht linear ist.

Rebase

Verwenden Sie den Befehl git rebase:

$ git rebase Origin/master

Dies weist Git an, Commit C (Ihre Arbeit) so abzuspielen, als hätten Sie es auf Commit B statt auf A festgelegt.
CVS- und Subversion-Benutzer stützen ihre lokalen Änderungen regelmäßig vor der vorgelagerten Arbeit ab, wenn sie vor dem Festschreiben eine Aktualisierung durchführen.
Git fügt nur eine explizite Trennung zwischen den Festschreibungs- und Rebase-Schritten hinzu.

Das Diagramm der Geschichte sieht nun so aus:

... o ---- o ---- A ---- B  Origin/master (upstream work)
                          \
                           C'  master (your work)

Commit C 'ist ein neues Commit, das mit dem Befehl git rebase erstellt wurde.
Es unterscheidet sich in zweierlei Hinsicht von C:

  1. Es hat eine andere Geschichte: B statt A.
  2. Sein Inhalt berücksichtigt Änderungen in B und C; es ist dasselbe wie M aus dem Zusammenführungsbeispiel. 

Beachten Sie, dass die Historie hinter C 'immer noch linear ist.
Wir haben (vorläufig) entschieden, nur die lineare Geschichte in cmake.org/cmake.git zuzulassen.
Dieser Ansatz bewahrt den zuvor verwendeten CVS-basierten Workflow und kann den Übergang erleichtern.
Ein Versuch, C 'in unser Repository zu verschieben, wird funktionieren (vorausgesetzt, Sie haben Berechtigungen und niemand hat während der Umbasierung gepusht).

Der Befehl git pull bietet eine Abkürzung für das Abrufen von Origin und die Wiederherstellung der lokalen Arbeit darauf:

$ git pull --rebase

Dadurch werden die oben genannten Abruf- und Rebase-Schritte in einem Befehl kombiniert. 

873
VonC

Ich hatte dies und bin rätselhaft, was es verursacht hat, selbst nachdem ich die obigen Antworten gelesen hatte. Meine Lösung war zu tun

git reset --hard Origin/master

Dann setzt dies nur meine (lokale) Kopie des Masters (die ich vermeintlich vermasselt habe) auf den richtigen Punkt zurück, wie durch (Remote) Origin/Master dargestellt.

WARNING: Sie verlieren alle Änderungen, die noch nicht an Origin/master gesendet wurden.

561
skiphoppy
git pull --rebase Origin/master 

ist ein einzelner Befehl, der Ihnen meistens helfen kann.

Edit: Ruft die Commits vom Origin/Master ab und wendet Ihre Änderungen auf den neu abgerufenen Zweigverlauf an.

41
asitmoharna

Ich befand mich in dieser Situation, als ich versuchte, rebase einen Zweig zu erstellen, der einen entfernten Zweig verfolgte, und ich versuchte, ihn auf dem Master neu zu erstellen. In diesem Szenario werden Sie höchstwahrscheinlich Ihren Zweig finden, diverged und es kann ein Durcheinander verursachen, das nichts für Git Nubees ist!

Angenommen, Sie befinden sich auf dem Zweig my_remote_tracking_branch, der von master verzweigt wurde

$ git status

# Auf Zweig my_remote_tracking_branch

nichts festzuschreiben (Arbeitsverzeichnis sauber)

Und jetzt versuchen Sie, vom Meister zurückzugreifen als:

git Rebase Master

HALTEN SIE JETZT AN und sparen Sie sich Ärger! Verwenden Sie stattdessen Zusammenführen als:

git Merge Master

Ja, Sie werden in Ihrer Filiale zusätzliche Commits erhalten. Aber wenn Sie nicht auf "nicht divergierende" Zweige aus sind, ist dies ein viel reibungsloserer Arbeitsablauf als das erneute Basieren. Siehe dieses Blog für eine detailliertere Erklärung.

Wenn Ihr Zweig jedoch nur ein local Zweig ist (dh noch nicht an eine entfernte Stelle weitergeleitet), sollten Sie auf jeden Fall einen Rebase durchführen (und Ihr Zweig wird dies nicht tun diverge in diesem Fall).

Wenn Sie dies jetzt lesen, weil Sie bereits sind in einem "divergierenden" Szenario aufgrund einer solchen Rebase sind, können Sie zum letzten Commit von Origin zurückkehren (dh in einem nicht divergierenden Zustand) unter Verwendung von:

git reset --hard Origin/my_remote_tracking_branch

28
paneer_tikka

In meinem Fall ist das, was ich getan habe, um die diverged message zu bewirken: Ich habe git Push gemacht, aber dann git commit --amend, um der Commit-Nachricht etwas hinzuzufügen. Dann habe ich noch ein Commit gemacht.

In meinem Fall bedeutete das einfach, dass Origin/Master veraltet war. Da ich wusste, dass niemand sonst Origin/Master berührte, war der Fix trivial: git Push -f (wobei -f force bedeutet)

20
Darren Cook

In meinem Fall habe ich Änderungen an Origin/master vorgenommen, und dann wurde mir klar, dass ich das nicht hätte tun sollen :-( Dies wurde dadurch erschwert, dass die lokalen Änderungen in einem Teilbaum waren. Ich ging also zum letzten guten Commit vor dem "schlechten" lokale Änderungen (mit SourceTree) und dann bekam ich die "Divergenz-Nachricht".

Nachdem ich mein Chaos lokal repariert hatte (die Details sind hier nicht wichtig), wollte ich den entfernten Origin/master-Zweig "in der Zeit zurückversetzen", damit er wieder mit der lokalen master synchron wäre. Die Lösung in meinem Fall war:

git Push Origin master -f

Beachten Sie den Schalter -f (force). Dadurch wurden die "fehlerhaften Änderungen" gelöscht, die versehentlich in Origin/master verschoben wurden, und jetzt sind die lokalen und fernen Verzweigungen synchron.

Bitte beachten Sie, dass dies eine potenziell zerstörerische Operation ist. Führen Sie sie daher nur aus, wenn Sie zu 100% sicher sind, dass der Remote-Master rechtzeitig zurückbewegt wird.

6
Laryx Decidua

Ich weiß, dass es hier viele Antworten gibt, aber ich denke, git reset --soft HEAD~1 verdient etwas Aufmerksamkeit, da Sie dadurch Änderungen im letzten local (nicht gedrückt) Commit beibehalten können, während Sie den abweichenden Zustand lösen. Ich denke, dass dies eine vielseitigere Lösung ist als Pull mit rebase, da das lokale Commit überprüft und sogar in einen anderen Zweig verschoben werden kann.

Der Schlüssel verwendet --soft anstelle des harten --hard. Wenn mehr als ein Commit vorhanden ist, sollte eine Variation von HEAD~x funktionieren. Hier sind alle Schritte, die meine Situation gelöst haben (ich hatte 1 lokales Commit und 8 Commits in der Fernbedienung):

1) git reset --soft HEAD~1, um das lokale Commit rückgängig zu machen. Für die nächsten Schritte habe ich die Schnittstelle in SourceTree verwendet, aber ich denke, die folgenden Befehle sollten auch funktionieren:

2) git stash, um Änderungen von 1) zu speichern. Nun sind alle Änderungen sicher und es gibt keine Divergenz mehr.

3) git pull, um die Remote-Änderungen abzurufen.

4) git stash pop oder git stash apply, um die letzten zwischengespeicherten Änderungen anzuwenden, und, falls gewünscht, ein neues Commit. Dieser Schritt ist optional zusammen mit 2) , wenn die Änderungen im lokalen Commit verworfen werden sollen. Wenn Sie sich für einen anderen Zweig festlegen möchten, sollten Sie diesen Schritt nach dem Umschalten auf den gewünschten Zweig ausführen. 

4
Bianca D.

Um die Unterschiede zu sehen:

git difftool --dir-diff master Origin/master

Dadurch werden die Änderungen oder Unterschiede zwischen den beiden Zweigen angezeigt. In araxis (Mein Favorit) wird es in einem Ordner-Diff-Stil angezeigt. Zeigt jede der geänderten Dateien an. Ich kann dann auf eine Datei klicken, um die Details der Änderungen in der Datei anzuzeigen.

4
C Johnson

In meinem Fall wurde dies dadurch verursacht, dass ich meine Konfliktlösung nicht begangen habe.

Das Problem wurde durch Ausführen des Befehls git pull verursacht. Änderungen im Origin führten zu Konflikten mit meinem lokalen Repo, die ich gelöst habe. Ich habe sie jedoch nicht festgelegt. Die Lösung an dieser Stelle ist, die Änderungen zu übernehmen (git commit die aufgelöste Datei)

Wenn Sie seit dem Lösen des Konflikts auch einige Dateien geändert haben, zeigt der Befehl git status die lokalen Änderungen als nicht bereitgestellte lokale Änderungen an und die Zusammenführungsauflösung als lokale lokale Änderungen. Dies kann ordnungsgemäß gelöst werden, indem Änderungen aus der Zusammenführung zuerst durch git commit übernommen werden. Anschließend werden die nicht bereitgestellten Änderungen wie üblich (z. B. git commit -a) hinzugefügt und festgelegt. 

Dieses Problem ist aufgetreten, als ich einen Zweig basierend auf Zweig A von erstellt habe

git checkout -b a

und dann stelle ich den Aufwärtsstrom von Zweig a auf Ursprungszweig B durch

git branch -u Origin/B

Dann habe ich die Fehlermeldung oben bekommen.

Eine Möglichkeit, dieses Problem für mich zu lösen, war:

  • Löschen Sie den Zweig a
  • Erstellen Sie einen neuen Zweig b von
git checkout -b b Origin/B
0
Shouheng Wang

Ich hatte dieselbe Nachricht, als ich versuchte, die letzte Festschreibungsnachricht zu bearbeiten, und zwar mit: git commit --amend -m "New message" Wenn ich die Änderungen mit git Push --force-with-lease repo_name branch_name

0
LoveForDroid