如何编辑或改写合并提交的消息？
git commit --amend 如果是最后一次提交 (HEAD) 有效，但如果它在 HEAD 之前呢？
git rebase -i HEAD~5 没有列出合并提交。
【问题讨论】：
git rebase -i -p 还是git rebase -i -r，您所做的是重新执行合并。如果原来的合并有合并冲突，重新执行时会再次出现。 (2) 与所有变基操作一样，这使得 new 提交；旧的提交仍然存在，但会从此分支中放弃。
~5 代表什么？
HEAD~5 指的是当前提交的伟大伟大伟大祖父母。见git help rev-parse。
如果您将--preserve-merges 选项（或其同义词-p）添加到git rebase -i 命令，那么git 将在变基时尝试保留合并，而不是线性化历史记录，您应该能够修改合并提交：
git rebase -i -p HEAD~5
注意。从 git v2.22 (https://www.infoq.com/news/2019/07/git-2-22-rebase-merges/) 开始，--perserve-merges 已被弃用，取而代之的是 --rebase-merges。
【讨论】：
! [rejected] HEAD -> master (non-fast-forward)error: failed to push some refs to
HEAD~5 是您要修改的提交的父级（通常是 sha1^）。
--preserve-merges 现在是 --rebase-merges
git rebase -i HEAD~5 命令弹出编辑器。它列出了指定的提交（在本例中为五个）。第一列包含每个提交的pick。只需在该编辑器中将pick 替换为reword 并保存+关闭编辑器。然后 git 将为您将 pick 更改为 reword 的每个提交弹出编辑器，并允许您编辑提交消息。
【讨论】：
-p 添加到git rebase 命令中。
请注意，starting git1.7.9.6（和 git1.7.10+），git merge 本身将始终触发编辑器，以便您将详细信息添加到合并中。
"
git merge $tag" 合并带注释的标签总是在交互式编辑会话期间打开编辑器。 v1.7.10 系列引入了一个环境变量 GIT_MERGE_AUTOEDIT 来帮助旧脚本拒绝这种行为，但维护轨道也应该支持它。
它还引入了一个环境变量 GIT_MERGE_AUTOEDIT 来帮助旧脚本拒绝这种行为。
最近在discussion on the Git mailing list 中，Linus 承认（我同意）这是我们在 Git 历史早期犯下的设计错误之一。
在 1.7.10 及更高版本中，在交互式会话中运行的 git merge 命令（即其标准输入和连接到终端的标准输出）将在创建提交以记录合并结果之前打开一个编辑器，以给出用户有机会解释合并，就像用户在解决冲突合并后运行的 git commit 命令一样。
林纳斯说：
但我并不真正关心它实际上是如何工作的——我的主要问题是 git 太容易产生错误的合并消息。
我认为其中一部分是一个更简单的白痴：默认情况下，我们甚至不会为“git merge”启动编辑器，但我们会为“git commit”启动。
那是一个设计错误，这意味着如果你想在合并中实际添加一个注释，你必须做额外的工作。所以人们不会。
请注意，在 Git 2.17（2018 年第二季度）之前，“git rebase -p”会损坏合并提交的日志消息，现已修复。
见commit ed5144d（2018 年 2 月 8 日）Gregory Herrero (``)。
推荐人：Vegard Nossum (vegard) 和 Quentin Casasnovas (casasnovas)。
（由 Junio C Hamano -- gitster -- 合并于 commit 8b49408，2018 年 2 月 27 日）
rebase -p：修复调用git merge时的错误提交信息。由于commit dd6fb00（“
rebase -p: fix quoting when callinggit merge”，2018 年 1 月，Git 2.16.0-rc2），rebase 的合并提交的提交消息使用子shell执行'git rev-parse --sq-quote'。这个子shell需要双引号，所以换行符是 为
git merge命令保留。在此补丁之前，以下合并消息：
"Merge mybranch into mynewbranch Awesome commit."变成：
"Merge mybranch into mynewbranch Awesome commit."在
rebase -p之后。
使用 Git 2.23（2019 年第二季度），“git rebase --rebase-merges”期间的“merge -c”指令应该让用户有机会编辑日志消息，即使在其他情况下不需要创建新的合并和替换现有的
一个（即快进代替），但没有。
已更正。
参见Phillip Wood (phillipwood) 的commit 6df8df0（2019 年 5 月 2 日）。
（由 Junio C Hamano -- gitster -- 合并于 commit c510261，2019 年 6 月 13 日）
【讨论】：
另一个只使用原始命令的好答案——由 knittl https://stackoverflow.com/a/7599522/94687:
git checkout <sha of merge>
git commit --amend # edit message
git rebase HEAD previous_branch
或更好（更正确）的最终变基命令：
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 flow 并在开发分支上重新建立基础并在没有快进的情况下合并到它，这可能会很有用。
【讨论】：
【讨论】：
merge -C 替换为merge -c（在 git-rebase-todo 文件中）并像往常一样启动 rebase（通过保存 todo 文件）后，rebase 应该在该合并提交上停止并且编辑器应该弹出允许您更改提交消息。就像您可以通过在 todo 文件中将 pick 替换为 reword 来改写正常的提交消息一样。
使用--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。
【讨论】：