Git-Merge-Berichte "Bereits aktuell", obwohl es einen Unterschied gibt

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

Es gibt Unterschiede zwischen Master- und Testzweigen.

Beide Niederlassungen haben alle Änderungen festgeschrieben.

Wenn ich mache:

Git Checkout Master

Git Diff Test

Ein Bildschirm voller Änderungen zeigt die Unterschiede an. Ich möchte die Änderungen im Testzweig zusammenführen und Folgendes tun:

Git Merge Test

Aber erhalten Sie die Meldung "Bereits aktuell"

Das Untersuchen von Dateien unter den einzelnen Zweigen zeigt jedoch deutlich Unterschiede.

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

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

Verwenden Sie gitkdiese Option , um einen Blick auf Ihr Repository zu werfen. Das Etikett für den Zweig "Test" sollte sich irgendwo unter Ihrem Etikett für den Zweig "Master" befinden.

Ihre Niederlassung ist in Bezug auf ihre Muttergesellschaft auf dem neuesten Stand. Laut Zusammenführung gibt es seit der letzten Zusammenführung keine neuen Änderungen im übergeordneten Element. Das bedeutet nicht, dass die Zweige gleich sind, da Sie in Ihrem Arbeitszweig viele Änderungen vornehmen können und es sich so anhört, als ob Sie dies tun.

Bearbeiten 10/12/2019:

Laut Charles Drake im Kommentar zu dieser Antwort lautet eine Lösung zur Behebung des Problems:

git checkout master
git reset --hard test

Dies bringt es zurück auf das "Test" -Niveau.

Dann mach:

git push --force origin master

um Änderungen zurück zum zentralen Repo zu erzwingen.

Dies passiert mir oft, wenn ich weiß, dass es Änderungen am Remote-Master gibt, und ich versuche, sie mithilfe von zusammenzuführen git merge master. Dies wird jedoch nicht mit dem Remote-Master, sondern mit Ihrem lokalen Master zusammengeführt.

Also, bevor Sie die Zusammenführung durchführen, checken Sie den Master aus und dann git pulldort. Dann können Sie die neuen Änderungen in Ihrer Filiale zusammenführen.

Angenommen, Sie haben einen Zweig mastermit dem folgenden Festschreibungsverlauf:

A -- B -- C -- D

Jetzt erstellen Sie einen Verzweigungstest, arbeiten daran und führen 4 Commits durch:

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

masterDer Kopf zeigt auf D und testder Kopf zeigt auf H.

Die Meldung "Bereits aktuell" wird angezeigt, wenn der HEAD des Zweigs, in den Sie zusammenführen, ein übergeordnetes Element der Commit-Kette des Zweigs ist, den Sie zusammenführen möchten. Das ist hier der Fall: Dist ein Elternteil von E.

Es gibt nichts zu Druck aus testzu master, da nichts geändert hat masterseitdem. Was Sie hier tun möchten, ist buchstäblich, Git zu sagen, dass masterder Kopf auf H zeigen soll, sodass der Master-Zweig die folgende Commit-Historie hat:

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

Dies ist ein Job für den Git-Befehl reset. Sie möchten auch, dass das Arbeitsverzeichnis diese Änderung widerspiegelt, sodass Sie einen Hard- Reset durchführen:

git reset --hard H

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

Sie öffnen die git-Befehlszeile, gehen zum Stammordner von branch2 und geben Folgendes ein:

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

Wenn Sie Konflikte haben, müssen Sie keinen Git-Push ausführen, sondern zuerst die Konflikte lösen und dann drücken.

Eine Zusammenführung erfolgt immer zwischen dem aktuellen HEAD und einem oder mehreren Commits (normalerweise Verzweigungskopf oder Tag),
und die Indexdatei muss zu Beginn mit dem Baum des HEAD-Commits (dh dem Inhalt des letzten Commits) übereinstimmen.
Mit anderen Worten, git diff --cached HEADmuss keine Änderungen melden.

Das zusammengeführte Commit ist bereits in enthalten HEAD. Dies ist der einfachste Fall mit der Bezeichnung "Bereits aktuell".

Das sollte bedeuten, dass die Commits im Test bereits im Master zusammengeführt sind, aber da andere Commits auf dem Master ausgeführt werden, git diff testwürde dies immer noch einige Unterschiede ergeben.

Dies liegt daran, dass Ihre lokale Kopie des Zweigs, den Sie zusammenführen möchten, veraltet ist. Ich habe meinen Zweig angerufen MyBranchund möchte ihn zusammenführen ProjectMaster.

_>git status
On branch MyBranch-Issue2
Your branch is up-to-date with 'origin/MyBranch-Issue2'.

nothing to commit, working tree clean

_>git merge ProjectMaster
Already up-to-date.

Aber ich weiß, dass es Änderungen gibt, die zusammengeführt werden müssen!

Wenn ich git merge ProjectMastertippe, sieht sich git meine lokale Kopie dieses Zweigs an, die möglicherweise nicht aktuell ist . Um zu sehen, ob dies der Fall ist, fordere ich Git zunächst auf, zu überprüfen, ob meine Zweige veraltet sind, und Änderungen abzurufen, wenn dies der Fall ist fetch. Dann hüpfe ich in den Zweig, den ich zusammenführen möchte, um zu sehen, was dort passiert ...

_>git fetch origin

_>git checkout ProjectMaster
Switched to branch ProjectMaster
**Your branch is behind 'origin/ProjectMaster' by 85 commits, and can be fast-forwarded.**
  (use "git pull" to update your local branch)

Ah-ha! Meine lokale Kopie ist um 85 Commits veraltet, das erklärt alles! Jetzt Pullschreibe ich die fehlenden Änderungen auf, gehe dann zu MyBranchund versuche die Zusammenführung erneut.

_>git pull
Updating 669f825..5b49912
Fast-forward

_>git checkout MyBranch-Issue2
Switched to branch MyBranch-Issue2
Your branch is up-to-date with 'origin/MyBranch-Issue2'.

_>git merge ProjectMaster
Auto-merging Runbooks/File1.ps1
CONFLICT (content): Merge conflict in Runbooks/Runbooks/File1.ps1

Automatic merge failed; fix conflicts and then commit the result.

Und jetzt muss ich noch ein Problem beheben ...

Dies geschah mir, weil GIT seltsamerweise dachte, dass sich die lokale Niederlassung von der entfernten Niederlassung unterscheidet. Dies war im Zweigdiagramm sichtbar: Es wurden zwei verschiedene Zweige angezeigt: Fernbedienungen / Ursprung / Zweigname und Zweigname.

Die Lösung bestand einfach darin, das lokale Repo zu entfernen und es erneut von der Fernbedienung zu klonen. Auf diese Weise würde GIT verstehen, dass Remotes / origin / branch_name> und branch_name tatsächlich identisch sind, und ich könnte das ausgeben git merge branch_name.

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

git merge origin/mastergit merge masterarbeitete stattdessen für mich. Um den Master in den Feature-Zweig zu integrieren, können Sie Folgendes verwenden:

git checkout feature_branch
git merge origin/master

Stellen Sie sicher, dass Sie den Zweig, den Sie zusammenführen möchten, zuerst auschecken und dann abrufen (damit Ihre lokale Version mit der Remote-Version übereinstimmt).

Gehen Sie dann zurück zu Ihrem Zweig, für den Sie die Zusammenführung durchführen möchten, und Ihre Git-Zusammenführung sollte funktionieren.

passierte mir und wurde auf diese Seite geschickt, nicht sicher, ob ich das gleiche Szenario hatte, aber ich versuchte, diesen "Test" -Zweig "wieder zusammenzuführen".

Ich habe es also zuvor zusammengeführt, aber ich habe absichtlich einige spezifische Änderungen während dieser Zusammenführung ausgeschlossen, sodass es eindeutig Unterschiede zwischen den Zweigen gibt. Ich habe dann versucht, es erneut zusammenzuführen, weil mir klar wurde / vergessen wurde, dass ich eine bestimmte Änderung / Datei hinzufügen sollte und wollte, die ich zuvor ausgeschlossen hatte, und ich hatte gehofft, wenn ich sie erneut zusammenführe, würden alle Änderungen angezeigt, die ich zuvor ausgeschlossen habe , aber ich habe mich geirrt und erhalte stattdessen die Meldung "Bereits aktuell".

Beim Lesen von @ Bombes Kommentar / Antwort hat er Recht, und ich denke, er verhält sich so. Ich habe also die Dateien im Testzweig hart gesichert, dann den Hauptzweig ausgecheckt und die Dateien manuell eingefügt und festgeschrieben es, als ob es neue Änderungen wären.

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

Wenn das Zusammenführen von Zweig A mit Zweig B "Bereits aktuell" meldet, ist die Umkehrung nicht immer der Fall. Es ist nur wahr, wenn Zweig B von Zweig A abstammt, andernfalls kann Zweig B einfach Änderungen haben, die nicht in A sind.

Beispiel:

1. Sie legen die Zweige A und B außerhalb des Masters an
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 nehmen einige Änderungen in Zweig A vor und führen A mit B zusammen.

Zu diesem Zeitpunkt meldet das Zusammenführen von A zu B "Bereits aktuell", aber die Zweige sind unterschiedlich, da Zweig B Aktualisierungen vom Master hat, Zweig A jedoch nicht.

Konfrontierte dieses Szenario mit Git Bash.

Unser Repository verfügt über mehrere Zweige, und jeder Zweig hat einen anderen Festschreibungszyklus, und die Zusammenführung erfolgt gelegentlich. Old_Branch wurde als übergeordnetes Element für New_Branch verwendet

Old_Branch wurde mit einigen Änderungen aktualisiert, die mit New_Branch zusammengeführt werden mussten

Verwenden Sie den folgenden Pull-Befehl ohne Verzweigung, um alle Quellen aus allen Verzweigungen abzurufen.

Git Pull Ursprung

Seltsamerweise zieht dies nicht alle Commits aus allen Zweigen. Hatte es so gedacht, da das angegebene fast alle Zweige und Tags zeigt.

Um dies zu beheben, hatte die Old_Branch die neueste Verwendung gezogen

Git Checkout Old_Branch

Git Pull Ursprung Old_Branch

Jetzt ausgecheckt New_Branch

Git Checkout New_Branch

Zog es, um sicher zu sein

Git Pull Ursprung New_Branch

git merge Old_Branch

Und Viola bekam Konflikte von Old_Branch zu New_Branch :), die erwartet wurden

Das gleiche ist mir passiert. Aber das Szenario war etwas anders, ich hatte einen Hauptzweig und ich habe release_1 (sagen wir) daraus herausgearbeitet. Im Zweig release_1 wurden einige Änderungen vorgenommen und mit dem Ursprung zusammengeführt. dann habe ich ssh gemacht und auf dem remote server habe ich release_1 wieder mit dem befehl git checkout -b release_1 ausgecheckt - der tatsächlich einen neuen branch release_ herausarbeitet! vom Master, anstatt den bereits vorhandenen Zweig release_1 vom Ursprung auszuchecken. Das Problem wurde durch Entfernen des Schalters "-b" behoben

Ich hatte das gleiche Problem. Ich hatte Änderungen an der Fernbedienung und es wurde immer noch "Bereits auf dem neuesten Stand" angezeigt. Das erneute Klonen des Repositorys hat das Problem für mich behoben.

Dumm, aber es könnte passieren. Angenommen, Ihrem Filialnamen wird beispielsweise eine Problemreferenz vorangestellt #91-fix-html-markup, wenn Sie diese Zusammenführung durchführen:

$ git merge #91-fix-html-markup

es wird nicht wie beabsichtigt funktionieren, weil alles nach dem #ignoriert wird, weil# ein Inline-Kommentar startet.

In diesem Fall können Sie den Zweig ohne #Namen umbenennen oder den Namen des Zweigs in einfache Anführungszeichen setzen : git merge '#91-fix-html-markup'.