Git：如何编辑/改写合并提交的消息？

Git: How to edit/reword a merge commit's message?

提问by ma11hew28

How do I edit or reword a merge commit's message?

如何编辑或改写合并提交的消息？

git commit --amendworks if it's the last commit made (HEAD), but what if it comes before HEAD?

git commit --amend如果它是最后一次提交 ( HEAD) 则有效，但如果它在之前HEAD呢？

git rebase -i HEAD~5doesn't list the merge commits.

git rebase -i HEAD~5不列出合并提交。

回答by Mark Longair

If you add the --preserve-mergesoption (or its synonym, -p) to the git rebase -icommand then git will try to preserve the merges when rebasing, rather than linearizing the history, and you should be able to amend the merge commits as well:

如果您将--preserve-merges选项（或其同义词，-p）添加到git rebase -i命令中，那么 git 将在重新设定基准时尝试保留合并，而不是线性化历史，您也应该能够修改合并提交：

git rebase -i -p HEAD~5

回答by VonC

Note that, starting git1.7.9.6(and git1.7.10+), git mergeitself will always trigger the editor, for you to add details to a merge.

请注意，从 git1.7.9.6（和 git1.7.10+）开始，git merge它本身将始终触发 editor，以便您向合并添加详细信息。

"git merge $tag" to merge an annotated tag always opens the editor during an interactive edit session. v1.7.10 series introduced an environment variable GIT_MERGE_AUTOEDIT to help older scripts decline this behaviour, but the maintenance track should also support it.

git merge $tag在交互式编辑会话期间，用于合并注释标签的“ ”始终会打开编辑器。v1.7.10 系列引入了一个环境变量 GIT_MERGE_AUTOEDIT 来帮助旧脚本拒绝这种行为，但维护轨道也应该支持它。

It also introduces an environment variable GIT_MERGE_AUTOEDITto help older scripts declinethis behavior.

它还引入了一个环境变量GIT_MERGE_AUTOEDIT来帮助旧脚本拒绝这种行为。

See "Anticipating Git 1.7.10":

参见“期待 Git 1.7.10”：

Recently in a discussion on the Git mailing list, Linus admitted (and I agreed) that this was one of the design mistakes we made early in the history of Git.
And in 1.7.10 and later, the git merge command that is run in an interactive session (i.e. both its standard input and its standard output connected to a terminal) will open an editor before creating a commit to record the merge result, to give the user a chance to explain the merge, just like the git commit command the user runs after resolving a conflicted merge already does.

最近在关于 Git 邮件列表的讨论中，Linus 承认（并且我同意）这是我们在 Git 历史早期犯的设计错误之一。
在 1.7.10 及更高版本中，在交互式会话中运行的 git merge 命令（即其标准输入和标准输出都连接到终端）将在创建提交之前打开一个编辑器来记录合并结果，以给出用户有机会解释合并，就像用户在解决合并冲突后运行的 git commit 命令一样。

Linus said:

莱纳斯说：

But I don't really care deeply how it actually works - my main issue is that git makes it way too easy to have bad merge messages.
I think part of that is an even simpler idiocy: we never even fire up the editor by default for a "git merge", but we do for a "git commit".
That was a design mistake, and it means that if you want to actually add a note to a merge, you have to do extra work. So people don't.

但我并不真正关心它的实际工作方式 - 我的主要问题是 git 使合并错误消息变得太容易了。
我认为其中的一部分是一个更简单的白痴：我们甚至从未默认为“git merge”启动编辑器，但我们为“ git commit”启动了。
这是一个设计错误，这意味着如果你想真正地向合并添加一个注释，你必须做额外的工作。所以人们不会。

---

---

Note that, before Git 2.17 (Q2 2018), "git rebase -p" mangled log messages of a merge commit, which is now fixed.

请注意，在 Git 2.17（2018 年第二季度）之前，" git rebase -p" 对合并提交的日志消息进行了损坏，现已修复。

See commit ed5144d(08 Feb 2018) by Gregory Herrero (``).
Suggested-by: Vegard Nossum (vegard), and Quentin Casasnovas (casasnovas).
^{(Merged by Junio C Hamano -- gitster--in commit 8b49408, 27 Feb 2018)}

请参阅Gregory Herrero (``) 的commit ed5144d(08 Feb 2018 )。
建议人：Vegard Nossum ( vegard)和Quentin Casasnovas ( casasnovas)。
^{（由Junio C gitsterHamano合并-- --在提交 8b49408 中，2018 年 2 月 27 日）}

rebase -p: fix incorrect commit message when calling git merge.

Since commit dd6fb00("rebase -p: fix quoting when calling git merge", January 2018, Git 2.16.0-rc2), the commit message of the merge commit being rebased is passed to the merge command using a subshell executing 'git rev-parse --sq-quote'.

Double quotes are needed around this subshell so that, newlines are kept for the git mergecommand.

Before this patch, following merge message:

"Merge mybranch into mynewbranch

Awesome commit."

becomes:

"Merge mybranch into mynewbranch Awesome commit."

after a rebase -p.

rebase -p：修复调用时不正确的提交消息git merge。

由于提交 dd6fb00（“ rebase -p：调用时修复引用git merge”，2018 年 1 月，Git 2.16.0-rc2），使用执行 ' git rev-parse --sq-quote'的子shell 将合并提交的提交消息传递给合并命令。

这个子shell需要双引号，以便为git merge命令保留换行符。

在此补丁之前，以下合并消息：

"Merge mybranch into mynewbranch

Awesome commit."

变成：

"Merge mybranch into mynewbranch Awesome commit."

之后rebase -p。

---

---

With Git 2.23 (Q2 2019), A "merge -c" instruction during "git rebase --rebase-merges" should give the user a chance to edit the log message, even when there is otherwise no need to create a new merge and replace the existing one (i.e. fast-forward instead), but did not.
Which has been corrected.

在 Git 2.23（2019 年第二季度）中，“ merge -c” 期间的“ ” 指令git rebase --rebase-merges应该让用户有机会编辑日志消息，即使不需要创建新的合并并替换现有的合并（即快进代替） )，但没有。
已更正。

See commit 6df8df0(02 May 2019) by Phillip Wood (phillipwood).
^{(Merged by Junio C Hamano -- gitster--in commit c510261, 13 Jun 2019)}

请参阅Phillip Wood ( )提交的 6df8df0(2019 年 5 月 2 日)。^{（由Junio C Hamano合并-- --在提交 c510261 中，2019 年 6 月 13 日）}phillipwood
gitster

回答by imz -- Ivan Zakharyaschev

Another nice answer using only primitive commands -- by knittl https://stackoverflow.com/a/7599522/94687:

仅使用原始命令的另一个不错的答案 - knittl https://stackoverflow.com/a/7599522/94687：

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

or a better (more correct) final rebase command:

或者更好（更正确）的最终 rebase 命令：

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

BTW, using the primitive commands might have the nice "feature" of not consuming too much CPU and making you wait unknown time until Git finishes thinking about the list of commits needing to be rebased in the case of git rebase -p -i HEAD^^^^(such a command which would result in a list of only 4 last commits with the merge as last one in my case in my case took around 50 secs!).

顺便说一句，使用原始命令可能有一个很好的“功能”，即不会消耗太多 CPU 并让您等待未知时间，直到 Git 完成考虑需要在这种情况下重新定位的提交列表git rebase -p -i HEAD^^^^（这样的命令会导致在我的案例中，只有 4 个最后提交的列表与合并作为最后一个在我的情况下花费了大约 50 秒！）。

回答by Do-do-new

git merge --edit
Allows you to give the comment even in case of non-interactive merge.

git merge --edit
即使在非交互式合并的情况下，也允许您提供评论。

git merge --edit --no-ffcan be useful if you follow git flow with rebasing on development branch and merging into it with no fast forward.

git merge --edit --no-ff如果您遵循 git flow 并在开发分支上重新定位并在没有快进的情况下合并到其中，则可能会很有用。

回答by Eugen Labun

For current Git versions (Mai 2020):

对于当前的 Git 版本（Mai 2020）：

git rebase -i -r <parent>,

git rebase -i -r <parent>,

then replace in the editor merge -C ...with merge -c ....

然后在编辑器中替换merge -C ...为merge -c ....

This will open the commit message in the editor during rebasing, where you can change it.

这将在变基期间在编辑器中打开提交消息，您可以在其中更改它。

(Thanks to VonCfor the hint.)

（感谢VonC的提示。）

回答by ChrisD

The git rebase -i HEAD~5command pops up the editor. It lists the specified commits (in this case five of them). The first column contains pickfor every commit. Just replace pickwith rewordin that editor and save+close the editor. Then git will pop up the editor for every commit where you changed pickto rewordand will let you edit the commit message.

该git rebase -i HEAD~5命令弹出编辑器。它列出了指定的提交（在本例中为五个）。第一列包含pick每个提交。只需在该编辑器中替换pick为reword并保存+关闭编辑器。Git会弹出编辑为每一个承诺，你改变pick对reword，将让你编辑提交信息。