Welche Auswirkungen hat das `--no-ff` Flag auf `git merge`?

Question

Beim Verwenden von gitk log konnte ich keinen Unterschied in der Wirkung von git merge und git merge --no-ff feststellen. Wie kann ich den Unterschied beobachten (mit einem git-Befehl oder einem Tool)?

Answer 1

Der --no-ff-Flag bewirkt, dass der Merge immer ein neues Commit-Objekt erstellt, auch wenn der Merge mit einem Fast-Forward durchgeführt werden könnte. Dadurch wird verhindert, dass Informationen über die historische Existenz eines Feature-Zweigs verloren gehen und alle Commits zusammengefasst werden, die zusammen das Feature hinzugefügt haben

Answer 2

Andere Antworten zeigen sehr gut, dass --no-ff zu einem Merge-Commit führt. Dies behält historische Informationen über den Feature-Zweig bei, was nützlich ist, da Feature-Zweige regelmäßig aufgeräumt und gelöscht werden.

Diese Antwort kann den Kontext dafür liefern, wann --no-ff verwendet werden sollte oder nicht.

Von Feature in den Hauptzweig zusammenführen: --no-ff verwenden

Arbeitsbeispiel:

$ git checkout -b NeuesFeature
[Arbeit...Arbeit...Arbeit]
$ git commit -am  "Neues Feature abgeschlossen!"
$ git checkout Hauptzweig
$ git merge --no-ff NeuesFeature
$ git push origin Hauptzweig
$ git branch -d NeuesFeature

Änderungen aus dem Hauptzweig in den Feature-Zweig zusammenführen: --no-ff weglassen

Arbeitsbeispiel:

$ git checkout -b NeuesFeature
[Arbeit...Arbeit...Arbeit]
[Neue Änderungen für HotFix im Hauptzweig gemacht! Lass sie uns holen...]
$ git commit -am  "Neues Feature in Bearbeitung"
$ git pull origin Hauptzweig
[Abkürzung für "git fetch origin Hauptzweig", "git merge origin Hauptzweig"]

Answer 3

Was ist ein Fast-Forward?

Ein Fast-Forward ist das, was Git tut, wenn du einen Merge oder Rebase gegen einen Zweig durchführst, der einfach vor dem von dir ausgecheckten liegt.

Gegeben die folgende Branch-Struktur:

Du hast beide Branches auf den gleichen Commit bezogen. Sie haben genau die gleiche Historie. Jetzt mach etwas in feature.

Der master-Zweig bezieht sich immer noch auf 7ddac6c, während feature sich um zwei Commits weiterentwickelt hat. Der Feature-Zweig kann jetzt als voraus gegenüber dem master angesehen werden.

Es ist jetzt relativ einfach zu sehen, was passiert, wenn Git einen Fast-Forward durchführt. Es aktualisiert einfach den master-Zweig, um genau auf den Commit zu verweisen, auf den auch feature verweist. Es werden keine Änderungen am Repository selbst vorgenommen, da die Commits aus feature bereits alle notwendigen Änderungen enthalten.

Deine Repository-Historie würde nun so aussehen:

Wann passiert kein Fast-Forward?

Fast-Forwards passieren nicht, wenn Änderungen im Originalzweig und im neuen Zweig vorgenommen wurden.

Wenn du versuchen würdest, feature auf master zu mergen oder rebasen, wäre Git nicht in der Lage, einen Fast-Forward durchzuführen, weil sich die Bäume beide auseinanderentwickelt haben. Da Git-Commits unveränderlich sind, gibt es keine Möglichkeit für Git, die Commits von feature in master zu übernehmen, ohne deren Elternreferenzen zu ändern.