Wenn Sie zwei Zweige zusammenführen, erstellt git ein separates Commit mit einer Nachricht wie Merge branch 'master' into my-branch .
Für eine nicht-triviale Zusammenführung ist es für mich klar, dass dies nützlich ist: Es bewahrt die Geschichte, wie die Dinge getrennt von anderen Änderungen zusammengeführt wurden. Wenn die Zusammenführung jedoch trivial ist (z. B. wenn die beiden Zweige keine gemeinsamen Dateien betreffen), Was ist der Zweck des separaten Zusammenführungs-Commits?
Sie können dieses Commit mit git merge --no-commit vermeiden. Sie könnten dann auch eine "echte" Änderung bei diesem Commit hinzufügen. Auf diese Weise vermeiden Sie ein scheinbar nutzloses Extra-Commit. Aber die Manpage warnt davor:
Sie sollten diese Option nicht missbrauchen, um wesentliche Änderungen in einen Merge-Commit einzuschleusen. Kleine Korrekturen wie der Release-Release- / Versions-Name wären akzeptabel.
Warum ist das so?
Mit commits mit echten Änderungen in ihnen markiert als o und merge-only commits als X , dies ist der Unterschied zwischen diesen beiden Situationen:
Warum ist der erste gegenüber dem zweiten vorzuziehen?
PS: Nehmen wir an, my-feature ist eine öffentliche Verzweigung, die auch von anderen verwendet wird. rebase wäre also keine Option.
Ich denke, es gibt mehrere Gründe, warum separate Merge-Commits sinnvoll sind, aber alles läuft auf die Grundregel hinaus, dass jedes Commit Änderungen enthalten sollte, die zusammengehören.
Mögliche Situationen, in denen Sie von separaten Zusammenführungs-Commits profitieren können:
Als zusätzlichen Vorteil erhalten Sie eine Geschichte, die einfacher zu verstehen ist. (Sie könnten eine Geschichte erhalten, die noch einfacher zu verstehen ist, wenn Sie rebase verwendet haben, aber Sie haben gesagt, das ist nicht möglich.)
An meinem Arbeitsplatz ist das "zentrale" Repository ein SVN-Server. Ich benutze Git über git-svn.
SVN führt (offensichtlich) keine schnellen Vorwärtsmischungen durch. Um also meine lokale Historie auf den Server zu replizieren, mache ich alle Merges, die extern sichtbar werden sollen, explizit.
Der Grund, warum Sie dieses Muster im allgemeinen Fall bevorzugen würden (zur Klärung: "Warum sollten Sie ein explizites Merge-Commit für eine Hauptkombination von zwei Zweigen wünschen, wie die Wiedervereinigung eines seit langem bestehenden Nebenzweiges, selbst wenn die zwei Konflikt nicht? ") ist, dass es bewirkt, dass das Repository die reale Reihe von durchgeführten Operationen besser widerspiegelt - das heißt, die Abstraktion für die Geschichte spiegelt besser die Realität wider von dieser Geschichte.
Wenn Sie vorspulen, gehen Informationen darüber verloren, wann die Integration stattgefunden hat - es gibt keinen Sinn in der Historie zu sagen "Hier ist, wenn X zu Y wurde" mit einer zugehörigen Nachricht.
Dies ist der gleiche Grund, aus dem manche Leute Merges anstelle von Rebasing selbst für ihre lokalen Filialen verwenden - Rebasing ist eine Form des Umschreibens von Geschichte, ein White-Lüge-auf-Papier.
Zu Ihrer anderen Frage - "warum sollten nur kleine Änderungen in einem Merge Commit sein" lautet die Antwort, dass der Merge Commit einen großen Unterschied in Bezug auf einige oder alle seiner Eltern haben kann. Wenn Sie also wichtige andere arbeiten, ist es sehr schwierig, herauszufinden, ob das Problem ein Integrationsproblem oder eine der neuen Änderungen war, die Sie hinzugefügt haben. Wenn Sie das Commit entweder auf einen der Eltern oder nach der Zusammenführung anwenden, wird die Halbierung vereinfacht, eine Portierung der Änderung durch Cherry-Pick ist möglich, Sie können die Zusammenführung umkehren, ohne Features zu verlieren usw.