Wie kann ich eine Vorschau einer Zusammenführung in Git anzeigen?

Question

Ich habe einen Git-Zweig (z. B. den Hauptzweig) und möchte einen anderen Entwicklungszweig einbinden. Oder muss ich das?

Um zu entscheiden, ob ich diesen Zweig wirklich zusammenführen möchte, würde ich gerne eine Art Vorschau sehen, was die Zusammenführung bewirken wird. Vorzugsweise mit der Möglichkeit, die Liste der Commits zu sehen, die angewendet werden.

Bislang ist das Beste, was mir einfällt merge --no-ff --no-commit und dann diff HEAD .

Answer 1

• git log ..otherbranch
  • Liste der Änderungen, die in den aktuellen Zweig übernommen werden.
• git diff ...otherbranch
  • diff vom gemeinsamen Vorgänger (Merge-Basis) bis zum Kopf dessen, was zusammengeführt werden soll. Beachten Sie die drei Punkte , die im Vergleich zu zwei Punkten eine besondere Bedeutung haben (siehe unten).
• gitk ...otherbranch
  • grafische Darstellung der Zweige seit der letzten Zusammenführung.

Leere Zeichenfolge impliziert HEAD und deshalb nur ..otherbranch anstelle von HEAD..otherbranch .

Die zwei bzw. drei Punkte haben für diff eine etwas andere Bedeutung als für die Befehle, die Revisionen auflisten (log, gitk usw.). Für log und andere haben zwei Punkte ( a..b ) bedeutet alles, was in b aber nicht a und drei Punkte ( a...b ) bedeutet alles, was nur in einer der folgenden Kategorien enthalten ist a o b . Aber diff arbeitet mit zwei Revisionen und dort mit dem einfacheren Fall, der durch zwei Punkte ( a..b ) ist der einfache Unterschied zu a a b und drei Punkte ( a...b ) mittlere Differenz zwischen gemeinsamem Vorfahren und b ( git diff $(git merge-base a b)..b ).

Answer 2

Ich habe festgestellt, dass die beste Lösung für mich darin besteht, dass ich einfach die Zusammenführung durchführen und bei Konflikten abbrechen . Diese spezielle Syntax erscheint mir sauber und einfach. Dies ist Strategie 2 unten.

Wenn Sie jedoch sicherstellen wollen, dass Sie Ihren aktuellen Zweig nicht durcheinander bringen, oder wenn Sie einfach nicht bereit sind, unabhängig von der Existenz von Konflikten zusammenzuführen, erstellen Sie einfach einen neuen Unterzweig davon und führen diesen zusammen:

Strategie 1: Der sichere Weg - Zusammenführen aus einem temporären Zweig:

git checkout mybranch
git checkout -b mynew-temporary-branch
git merge some-other-branch

Auf diese Weise können Sie den temporären Zweig einfach wegwerfen, wenn Sie nur sehen wollen, wo die Konflikte liegen. Sie müssen sich nicht die Mühe machen, die Zusammenführung "abzubrechen", und Sie können zu Ihrer Arbeit zurückkehren - checken Sie einfach "mybranch" wieder aus und Sie werden keinen zusammengeführten Code oder Konflikte in Ihrem Zweig haben.

Dies ist im Grunde ein Probelauf.

Strategie 2: Wenn Sie unbedingt fusionieren wollen, aber nur, wenn es keine Konflikte gibt

git checkout mybranch
git merge some-other-branch

Wenn git Konflikte meldet (und NUR WENN ES Konflikte) können Sie dann tun:

git merge --abort

Wenn die Zusammenführung erfolgreich ist, können Sie sie nicht abbrechen (nur zurücksetzen).

Wenn Sie noch nicht bereit sind, zu fusionieren, verwenden Sie den oben beschriebenen sichereren Weg.

[EDIT: 2016-Nov - Ich habe Strategie 1 gegen 2 ausgetauscht, da es scheint, dass die meisten Leute nach dem "sicheren Weg" suchen. Strategie 2 ist jetzt eher ein Hinweis darauf, dass man die Zusammenführung einfach abbrechen kann, wenn die Zusammenführung Konflikte hat, mit denen man nicht umgehen kann. Denken Sie daran, wenn Sie Kommentare lesen!]

Answer 3

Die meisten Antworten hier erfordern entweder ein sauberes Arbeitsverzeichnis und mehrere interaktive Schritte (schlecht für Skripte), oder sie funktionieren nicht in allen Fällen, z.B. bei vergangenen Merges, die bereits einige der ausstehenden Änderungen in den Zielzweig bringen, oder bei Cherry-Picks, die dasselbe tun.

Um wirklich zu sehen, was sich in der master Zweig, wenn Sie zusammengeführt haben develop und zwar jetzt sofort:

git merge-tree $(git merge-base master develop) master develop

Da es sich um einen Klempnerbefehl handelt, kann er nicht erraten, was Sie meinen, Sie müssen es explizit sagen. Außerdem wird die Ausgabe nicht eingefärbt oder Ihr Pager verwendet, so dass der vollständige Befehl lauten würde:

git merge-tree $(git merge-base master develop) master develop | colordiff | less -R

- https://git.seveas.net/previewing-a-merge-result.html

(Dank an David Normington für den Link)

P.S.:

Wenn es zu Konflikten beim Zusammenführen kommt, werden diese mit den üblichen Konfliktmarkierungen in der Ausgabe angezeigt, z. B.:

$ git merge-tree $(git merge-base a b ) a b 
added in both
  our    100644 78981922613b2afb6025042ff6bd878ac1994e85 a
  their  100644 61780798228d17af2d34fce4cfbdf35556832472 a
@@ -1 +1,5 @@
+<<<<<<< .our
 a
+=======
+b
+>>>>>>> .their

Der Benutzer @dreftymac hat ein gutes Argument: Das macht es für Skripting ungeeignet, weil man das nicht einfach aus dem Statuscode herauslesen kann. Die Konfliktmarkierungen können je nach Umstand recht unterschiedlich sein (gelöscht vs. geändert, etc.), was das Grepen ebenfalls erschwert. Vorsicht!

Answer 4

Wenn es Ihnen wie mir geht, suchen Sie nach einem Äquivalent zu svn update -n . Das folgende Beispiel scheint zu funktionieren. Achten Sie darauf, dass Sie eine git fetch damit Ihr lokales Repository über die entsprechenden Aktualisierungen verfügt, mit denen es verglichen werden kann.

$ git fetch origin
$ git diff --name-status origin/master
D       TableAudit/Step0_DeleteOldFiles.sh
D       TableAudit/Step1_PopulateRawTableList.sh
A       manbuild/staff_companies.sql
M       update-all-slave-dbs.sh

oder wenn Sie einen Unterschied zwischen Ihrem Kopf und der Fernbedienung wünschen:

$ git fetch origin
$ git diff origin/master

---

IMO ist diese Lösung viel einfacher und weniger fehleranfällig (und daher viel weniger riskant) als die oberste Lösung, die "Zusammenführen und dann Abbrechen" vorschlägt.

Answer 5

Wenn Sie die Änderungen bereits abgeholt haben, ist mein Favorit:

git log ...@{u}

Ich glaube aber, dass dafür Git 1.7.x erforderlich ist. Die @{u} Notation ist eine "Kurzschrift" für den vorgelagerten Zweig und damit ein wenig vielseitiger als git log ...origin/master .

Hinweis: Wenn Sie zsh und die erweiterte Glog-Funktion verwenden, müssen Sie wahrscheinlich etwas wie folgt tun:

git log ...@\{u\}