Git: Wie kann ich die Nachricht eines Merge-Commits bearbeiten/umformulieren?

Wie bearbeite oder formuliere ich die Nachricht eines Merge-Commits um?

git commit --amend funktioniert, wenn es das letzte Commit ist (HEAD), aber was ist, wenn es vorher kommt HEAD?

git rebase -i HEAD~5 listet die Merge-Commits nicht auf.

Wenn Sie die hinzufügen --preserve-merges Option (oder sein Synonym, -p) zum git rebase -i Befehl, dann wird git versuchen, die Merges beim Rebasing beizubehalten, anstatt den Verlauf zu linearisieren, und Sie sollten auch in der Lage sein, die Merge-Commits zu ändern:

git rebase -i -p HEAD~5

Notiz. --perserve-merges wurde zugunsten von verworfen --rebase-merges ab git v2.22 (https://www.infoq.com/news/2019/07/git-2-22-rebase-merges/).

Beachten Sie, dass, ab git1.7.9.6 (und git1.7.10+), git merge selbst wird immer den Editor auslösendamit Sie einer Zusammenführung Details hinzufügen können.

“git merge $tag” zum Zusammenführen eines annotierten Tags wird während einer interaktiven Bearbeitungssitzung immer der Editor geöffnet. Die v1.7.10-Serie hat eine Umgebungsvariable GIT_MERGE_AUTOEDIT eingeführt, um älteren Skripten zu helfen, dieses Verhalten abzulehnen, aber der Wartungspfad sollte es auch unterstützen.

Es führt auch eine Umgebungsvariable ein GIT_MERGE_AUTOEDIT um älteren Skripten zu helfen Ablehnen Dieses Verhalten.

Sehen “Vorwegnahme von Git 1.7.10“:

Kürzlich in einem Diskussion auf der Git-MailinglisteLinus gab zu (und ich stimmte zu), dass dies einer der Designfehler war, die wir früh in der Geschichte von Git gemacht haben.
Und in 1.7.10 und höher öffnet der Befehl git merge, der in einer interaktiven Sitzung ausgeführt wird (dh sowohl seine Standardeingabe als auch seine Standardausgabe, die mit einem Terminal verbunden sind), einen Editor, bevor er einen Commit erstellt, um das Ergebnis der Zusammenführung aufzuzeichnen dem Benutzer die Möglichkeit, die Zusammenführung zu erklären, genau wie der Befehl git commit, den der Benutzer ausführt, nachdem er eine kollidierte Zusammenführung gelöst hat, dies bereits tut.

Linus sagte:

Aber es interessiert mich nicht wirklich, wie es tatsächlich funktioniert – mein Hauptproblem ist, dass Git es viel zu einfach macht, schlechte Merge-Nachrichten zu haben.
Ich denke, ein Teil davon ist eine noch einfachere Idiotie: Wir starten den Editor nicht einmal standardmäßig für ein “git merge”, aber wir tun es für ein “git commit“.
Das war ein Designfehler, und es bedeutet, dass Sie zusätzliche Arbeit leisten müssen, wenn Sie tatsächlich eine Notiz zu einer Zusammenführung hinzufügen möchten. Also die Leute nicht.

Beachten Sie, dass vor Git 2.17 (Q2 2018) “git rebase -p” Verstümmelte Log-Meldungen eines Merge-Commits, was nun behoben ist.

Sehen Commit ed5144d (08.02.2018) von Gregor Herrero (“).
Vorgeschlagen von: Vegard Nossum (vegard)und Quentin Casasnovas (casasnovas).
^{(Zusammengeführt von Junio ​​C. Hamano — gitster — in Übertrage 8b4940827.02.2018)}

rebase -p: falsche Commit-Nachricht beim Aufrufen behoben git merge.

Seit dd6fb00 übergeben (“rebase -p: Zitieren beim Aufrufen behoben git
merge“, Januar 2018, Git 2.16.0-rc2), wird die Commit-Nachricht des rebasierenden Merge-Commits mithilfe einer Subshell an den Merge-Befehl übergeben, die ‘git rev-parse --sq-quote‘.

Um diese Subshell herum sind doppelte Anführungszeichen erforderlich, damit Zeilenumbrüche für die beibehalten werden git merge Befehl.

Vor diesem Patch folgende Zusammenführungsmeldung:

"Merge mybranch into mynewbranch

Awesome commit."

wird:

"Merge mybranch into mynewbranch Awesome commit."

nach einer rebase -p.

Mit Git 2.23 (Q2 2019), A “merge -c“Unterricht während”git rebase --rebase-merges” sollte dem Benutzer die Möglichkeit geben, die Protokollnachricht zu bearbeiten, auch wenn ansonsten keine Notwendigkeit besteht, eine neue Zusammenführung zu erstellen und die vorhandene zu ersetzen (dh stattdessen schnell vorzuspulen), dies jedoch nicht getan hat.
Was korrigiert wurde.

Sehen übertrage 6df8df0 (02. Mai 2019) von Philipp Holz (phillipwood).
^{(Zusammengeführt von Junio ​​C. Hamano — gitster — in c510261 übergeben13. Juni 2019)}

Eine weitere nette Antwort, die nur primitive Befehle verwendet – von knittl https://stackoverflow.com/a/7599522/94687:

git checkout <sha of merge>
git commit --amend # edit message
git rebase HEAD previous_branch

oder ein besserer (korrekterer) endgültiger Rebase-Befehl:

git rebase <sha of merge> previous_branch --onto HEAD

Übrigens, die Verwendung der primitiven Befehle könnte die nette “Funktion” haben, nicht zu viel CPU zu verbrauchen und Sie eine unbekannte Zeit warten zu lassen, bis Git damit fertig ist, über die Liste der Commits nachzudenken, die im Fall von neubasiert werden müssen git rebase -p -i HEAD^^^^ (Ein solcher Befehl, der in meinem Fall eine Liste von nur 4 letzten Commits mit dem Zusammenführen als letztem ergeben würde, dauerte in meinem Fall ungefähr 50 Sekunden!).

Für aktuelle Git-Versionen (2020+) einfach tun git rebase -i -r <parent>dann im Editor ersetzen merge -C mit merge -c. Dadurch wird die Nachricht des Merge-Commits während des Rebasings im Editor geöffnet, wo Sie sie ändern können (danke an VonC für den Hinweis).

Aktualisierung von 2021, -p ist veraltet.

Benutzen --rebase-merges stattdessen.

Verwenden Sie die --rebase-merges (oder die gekürzte -r) Flagge:

git rebase -i -r HEAD~5

Ändern Sie dann den „Pick“-Text in „edit“ oder „reword“ neben dem zu ändernden Commit:

pick <commit-hash-to-leave> <message>
edit <commit-hash-to-change> <message>

Der --rebase-merges Flag ersetzt das veraltete --preserve-merges (oder die gekürzte -p)

Dokumentation: https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt–r

git merge --edit

Ermöglicht es Ihnen, den Kommentar auch im Falle einer nicht interaktiven Zusammenführung abzugeben.

git merge --edit --no-ff

kann nützlich sein, wenn Sie dem Git-Flow folgen, indem Sie auf den Entwicklungszweig umbasieren und ihn ohne schnellen Vorlauf zusammenführen.