Git merge Berichte "Bereits auf dem neuesten Stand" obwohl es einen Unterschied gibt

Question

Ich habe ein Git-Repository mit 2 Filialen: Master und Test.

Es gibt Unterschiede zwischen Master- und Testfilialen.

Beide Zweige haben alle Änderungen festgeschrieben.

Wenn ich tun:

 
git checkout master
 
git diff test 

Ein Bildschirm voller Veränderungen, die Unterschiede erscheint zeigt. Ich möchte die Änderungen in dem Testzweig verschmelzen und so tun:

git merge test

Aber die Meldung „Bereits up-to-date“

jedoch Dateien unter jedem anderen Zweig der Prüfung zeigt deutlich Unterschiede.

Was ist das Problem hier und wie löse ich es?

Answer 1

Die Meldung "Bereits aktuell" bedeutet, dass alle Änderungen der Zweigstelle, die Sie zusammenführen möchten, bereits mit der Zweigstelle zusammengeführt wurden, in der Sie sich gerade befinden. Genauer gesagt bedeutet dies, dass der Zweig, den Sie zusammenführen möchten, ein Elternteil Ihres aktuellen Zweigs ist. Herzlichen Glückwunsch, das ist die einfachste Zusammenführung, die Sie jemals machen werden. :)

Verwenden Sie gitk, um sich Ihr Repository anzusehen. Das Label für den Zweig "Test" sollte irgendwo unter dem Label "Master" sein.

Ihre Zweigstelle ist in Bezug auf ihre Muttergesellschaft auf dem neuesten Stand. Nach der Zusammenführung gibt es seit der letzten Zusammenführung keine neuen Änderungen im Parent. Das bedeutet nicht, dass die Zweige gleich sind, weil Sie viele Änderungen in Ihrem Arbeitszweig haben können und es klingt wie Sie.

Answer 2

Ein Merge ist immer zwischen dem aktuellen HEAD und einem oder mehreren Commits (in der Regel, Filialleiter oder Tag),
und der Index-Datei muss der Baum des HEAD übereinstimmen begehen (dh der Inhalt des letzten Commit) wenn es anfängt.
Mit anderen Worten, git diff --cached HEAD muss keine Änderungen melden.

Das gemischte Commit ist bereits in HEAD enthalten. Dies ist der einfachste Fall, der "bereits auf dem neuesten Stand" genannt wird.

, dass die Commits in Tests sind bedeuten soll bereits im Master verschmolzen, aber da andere Commits auf Master fertig sind, würde git diff test noch einige Unterschiede geben.

Answer 3

Das passiert mir oft, wenn ich weiß, dass es Änderungen auf dem Remote-Master gibt, also versuche ich, sie unter Verwendung git merge master zusammenzuführen. Dies geht jedoch nicht mit dem Remote-Master, sondern mit Ihrem lokalen Master zusammen.

Bevor Sie die Zusammenführung durchführen, checken Sie den Master und dann git pull dort. Dann können Sie die neuen Änderungen in Ihren Zweig einfügen.

Answer 4

Das ist mir passiert, weil seltsam GIT dachte, dass der lokale Zweig anders als der entfernte Zweig war. Dies war in der Zweiggrafik sichtbar: Es wurden zwei verschiedene Zweige angezeigt: Fernbedienungen/Ursprung/Zweigname und Zweigname.

Die Lösung bestand einfach darin, den lokalen Repo zu entfernen und ihn remote erneut zu klonen. Auf diese Weise würde GIT verstehen, dass Fernbedienungen/Ursprung/Zweigname> und Zweigname in der Tat die gleichen sind, und ich könnte die git merge branch_name ausgeben.

rm <my_repo> 
git clone <my_repo> 
cd <my_repo> 
git checkout <branch_name> 
git pull 
git checkout master 
git merge <branch_name> 

Answer 5

Das gleiche ist mir passiert. Aber das Szenario war ein wenig anders, ich hatte Master-Zweig, und ich habe release_1 herausgebrochen. Einige Änderungen im Zweig release_1 wurden vorgenommen und in den Ursprung zusammengeführt. dann habe ich SSH und auf dem Remote-Server Ich wieder auschecken Release_1 mit dem Befehl git checkout -b release_1 - das tatsächlich eine neue Zweigfreigabe herausschneidet_! vom Master, anstatt den bereits vorhandenen Zweig release_1 aus dem Ursprung auszuprobieren. das Problem gelöst durch „-b“ -Schalter

Answer 6

Entfernen Sagen Sie bitte einen Zweig master mit der Geschichte haben folgende begehen:

A -- B -- C -- D

Nun Sie einen Zweig Test, Arbeit auf sie erstellen, und zu tun 4 Commits :

       E -- F -- G -- H 
       /
A -- B -- C -- D 

master den Kopf Punkte D und test den Kopf Punkte auf H.

„Al Bereit-up-to-date "-Nachricht wird angezeigt, wenn der HEAD des Zweigs, in den Sie zusammenführen, ein Elternteil der Kette von Commits des Zweigs ist, den Sie zusammenführen möchten. Das ist der Fall, hier: ist ein Elternteil von E.

Es gibt nichts zu verschmelzen von test zu master, seit nichts an master seitdem geändert hat. Was Sie hier tun möchten, ist buchstäblich Git zu sagen master den Kopf zu haben, um H-zu-Punkt, so Zweig Master hat die folgende Commits Geschichte:

A -- B -- C -- D -- E -- F -- G -- H

Dies ist ein Job für Git Befehl reset. Sie wollen auch das Arbeitsverzeichnis diese Änderung widerzuspiegeln, so dass Sie einen hart Reset durchführen:

git reset --hard H

Answer 7

Wenn Verschmelzung Zweig A in Zweig B Berichte „Bereits auf dem neuesten Stand“, umgekehrt ist nicht immer wahr . Es ist wahr, nur dann, wenn der Zweig B Abkömmling des Zweiges A ist, sonst Zweig B einfach Änderungen haben kann, die nicht in A. sind

Beispiel:

1. Sie erstellen Zweige A und B aus Master
2. Sie nehmen einige Änderungen im Master vor und führen diese Änderungen nur in Zweig B zusammen (nicht aktualisieren oder vergessen Zweig A zu aktualisieren).
3. Sie einige Änderungen in Zweig A machen und A

An dieser Stelle verschmelzen A nach B fusionieren Berichte „Bereits up to date“ B, aber die Zweige sind anders, weil Zweig B Updates von Master während Zweig hat A nicht.

Answer 8

Konfrontiert dieses Szenario mit Git Bash.

Unser Repository hat mehrere Verzweigungen und jeder Zweig hat einen anderen Commit-Zyklus und die Zusammenführung passiert hin und wieder. Old_Branch wurde New_Branch

als Eltern verwendet

Old_Branch mit einigen Änderungen aktualisiert wurde, die mit New_Branch verschmolzen werden benötigt, um

wurde ohne Zweig unter Pull-Befehl alle Quellen aus allen Branchen zu erhalten.

git pull Herkunft

Merkwürdig ist dies nicht alle Commits aus allen Zweigen ziehen. Hatte es so gedacht, da das Angezeigte fast alle Zweige und Tags zeigt.

So Um dies zu beheben hatte die Old_Branch ausgecheckt zog die neueste

mit

git Kasse Old_Branch

git pull Herkunft Old_Branch

Jetzt New_Branch ausgecheckt

git checkout New_Branch

es Pulled sicher Konflikte

git pull Herkunft New_Branch

git merge Old_Branch

Und Viola bekam zu sein von Old_Branch zu New_Branch zu beheben :) die

erwartet wurde

Answer 9

ist mir passiert und wurde auf diese Seite geschickt, nicht sicher, ob ich das gleiche Szenario hatte, aber meiner war der Versuch, fusioniere "das" test "branch".

Also habe ich es vorher verschmolzen, aber ich schließe absichtlich einige spezifische Änderungen während der Zusammenführung, so dass es eindeutig Unterschiede zwischen den Zweigen hat. Ich versuchte dann, es wieder zusammenzuführen, weil ich erkannte, dass ich eine bestimmte Änderung/Datei, die ich vorher ausgeschlossen hatte, hinzufügen wollte und wollte, dass ich alle Änderungen, die ich zuvor ausgeschlossen hatte, wieder einblenden würde , aber ich habe mich geirrt und bekomme stattdessen die Nachricht "Already up-to-date".

Nach dem Lesen @ Bombe's Kommentar/Antwort, hat er Recht, und git denke ich verhält sich so, also was ich getan habe, war eine harte Sicherung der Dateien auf Test-Zweig, dann check the Master-Zweig und manuell die Dateien einfügen darin und begehe es als ob es neue Änderungen wären.

bin nicht sicher, ob dies der richtige Weg ist oder anderen helfen könnte, das gleiche Problem zu haben, aber es hat eine Lösung für meinen speziellen Fall geliefert.

Answer 10

Was für mich funktioniert, nehmen wir an, Sie haben Branch1 und Sie möchten es in Branch2 zusammenführen.

Sie öffnen git Befehlszeile Stammordner branch2 und Art gehen:

git checkout branch1 
git pull branch1 
git checkout branch2 
git merge branch1 
git push 

Wenn Sie comflicts haben Sie brauchen, um git push nicht zu tun, sondern zuerst die conflits lösen und drücken dann.