如何编辑或改写合并提交的消息？
git commit --amend如果它是最后一次提交（HEAD），则有效，但如果它在之前HEAD呢？
git rebase -i HEAD~5没有列出合并提交。
问问题
90332 次
8 回答
246
如果您将--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
于 2011-09-02T04:47:46.630 回答
36
请注意，从 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 ”：
最近在Git 邮件列表的讨论中，Linus 承认（我同意）这是我们在 Git 历史早期犯下的设计错误之一。
在 1.7.10 及更高版本中，在交互式会话中运行的 git merge 命令（即其标准输入和连接到终端的标准输出）将在创建提交以记录合并结果之前打开一个编辑器，以给出用户有机会解释合并，就像用户在解决冲突合并后运行的 git commit 命令一样。
莱纳斯说：
但我并不真正关心它实际上是如何工作的——我的主要问题是 git 太容易产生错误的合并消息。
我认为其中一部分是一个更简单的白痴：默认情况下，我们甚至从未为“git merge”启动编辑器，但我们为“git commit”启动了编辑器。
那是一个设计错误，这意味着如果你想在合并中实际添加一个注释，你必须做额外的工作。所以人们不会。
请注意，在 Git 2.17（2018 年第 2 季度）之前，“ git rebase -p”会破坏合并提交的日志消息，现在已修复。
请参阅Gregory Herrero (``)的提交 ed5144d（2018 年 2 月 8 日） 。
推荐人：Vegard Nossum ( )和Quentin Casasnovas ( )。（由Junio C Hamano 合并 -- --在提交 8b49408中，2018 年 2 月 27 日）vegardcasasnovas
gitster
rebase -p：修复调用时不正确的提交信息git merge。自提交 dd6fb00 ("
rebase -p: fix quoting when callinggit merge", January 2018, Git 2.16.0-rc2) 以来，被 rebase 的合并提交的提交消息被传递给使用执行 '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 年第二季度），“ merge -c”期间的“”指令git rebase --rebase-merges应该让用户有机会编辑日志消息，即使在其他情况下不需要创建新的合并并替换现有的合并（即快进代替)，但没有。
已更正。
请参阅Phillip Wood ( ) 的提交 6df8df0（2019 年 5 月 2 日）。（由Junio C Hamano 合并 -- --在提交 c510261中，2019 年 6 月 13 日）phillipwood
gitster
于 2012-04-03T05:55:35.550 回答
21
仅使用原始命令的另一个不错的答案-通过 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 秒！）。
于 2017-03-01T15:34:35.567 回答
6
从 2021 年开始更新，-p已弃用。
改为使用--rebase-merges。
于 2021-01-26T16:15:00.753 回答
4
使用--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
于 2020-10-26T18:07:32.580 回答
3
git merge --edit
即使在非交互式合并的情况下，您也可以发表评论。
git merge --edit --no-ff
如果您遵循 git flow 并在开发分支上重新建立基础并在没有快进的情况下合并到它，这可能会很有用。
于 2018-04-08T13:12:57.353 回答
0
该git rebase -i HEAD~5命令弹出编辑器。它列出了指定的提交（在本例中为五个）。第一列包含pick每个提交。只需在该编辑器中替换pick为reword并保存+关闭编辑器。然后 git 将为您更改的每个提交弹出编辑器，pick并reword允许您编辑提交消息。
于 2012-01-10T05:24:19.607 回答