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

小开

最佳答案

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

git rebase -i -p HEAD~5

注意：从Git v2.22开始，--perserve-merges已被弃用，取而代之的是--rebase-merges（https：//www.infoq.com/news/2019/07/git-2-22-rebase-merges/）。

小开

编辑器弹出“git rebase -i HEAD~5 ”命令。它列出了指定的提交（在本例中为五个）。第一列包含每次提交的pick。只需在该编辑器中将pick替换为reword，然后保存并关闭编辑器。然后，Git将为您将pick更改为reword的每个提交弹出编辑器，并允许您编辑提交消息。

小开

请注意，正在启动git1.7.9.6（和GIT1.7.10+），git merge本身将始终触发编辑器，用于向合并添加详细信息。

“git merge $tag ”合并带注释的标签在交互式编辑会话期间始终会打开编辑器。V1.7.10系列引入了一个环境变量git_merge_autoedit来帮助旧的脚本减少这种行为，但是维护跟踪也应该支持它。

它还引入了一个环境变量GIT_MERGE_AUTOEDIT，以帮助较旧的脚本下降这种行为。

请参阅“期待Git 1.7.10 ”：

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

莱纳斯说：

但我并不真正关心它实际上是如何工作的-我的主要问题是，Git使它太容易有坏的合并消息。
我认为部分原因是一个更简单的愚蠢行为：我们甚至从来没有在默认情况下为“ Git合并”启动编辑器，但我们为“git commit ”启动编辑器。
这是一个设计错误，这意味着如果你想在合并中添加注释，你必须做额外的工作。所以人们不会.

请注意，在Git 2.17（2018年第2季度）之前，“git rebase -p ”会损坏合并提交的日志消息，该问题现已修复。

见提交ED5144D（2018年2月8日），由格雷戈里·埃雷罗（``）提出。
建议者：Vegard Nossum（vegard），Quentin Casasnovas（casasnovas）。
^{（由Junio C hamano--gitster--合并于提交8B49408，2018年2月27日）}

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

因为提交DD6FB00（rebase -p：修复调用Git时的引用 Merge，January 2018，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之后。

在Git 2.23（2019年第2季度）中，“git rebase --rebase-merges ”期间的“merge -c ”指令应使用户有机会编辑日志消息，即使不需要创建新的合并和替换现有的一个（即快进），但没有。
这一点已得到纠正。

见提交6DF8DF0（2019年5月2日），由Phillip Wood（phillipwood）提出。
^{（由Junio C hamano--gitster--合并于提交C510261，2019年6月13日）}

小开

另一个只使用原始命令的好答案--通过knittlhttps：//stackoverflow.com/a/7599522/94687：

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

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

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

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

小开

git merge --edit
即使在非交互式合并的情况下，也允许您给出注释。

git merge --edit --no-ff 如果您遵循Git流程，重新基于开发分支并合并到其中，而不是快速前进，则会非常有用。

小开

对于当前的Git版本（2020+），只需执行git rebase -i -r <parent>。然后在编辑器中将merge -C替换为merge -c。这将在重定基址期间在编辑器中打开合并提交的消息，您可以在其中更改它（感谢冯克提供的暗示）。

小开

使用--rebase-merges（或缩短的-r）标志：

git rebase -i -r HEAD~5

然后将提交更改旁边的“ Pick ”文本更改为“ Edit ”或“ Reword ”：

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

--rebase-merges标志取代了过时的--preserve-merges（或缩短的-p）。

文档：https：//git-scm.com/docs/git-rebase#documentation/git-rebase.txt--r

小开

更新自2021年起，不建议使用-p。

请改用--rebase-merges。

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

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

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