如何编辑或改写合并提交的消息？如果git commit --amend是最后一次提交（HEAD），那么git commit --amend可以工作，但是如果它出现在HEAD之前呢？git rebase -i HEAD~5不列出合并提交。
git commit --amend
HEAD
git rebase -i HEAD~5
wooyq4lh1#
如果你在git rebase -i命令中添加了--preserve-merges选项（或者它的同义词，-p），那么git会尝试在重定基时保留合并，而不是线性化历史记录，并且你也可以修改合并提交：
git rebase -i
--preserve-merges
-p
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。
--perserve-merges
--rebase-merges
pexxcrt22#
请注意，starting git1.7.9.6（和git1.7.10+），git merge本身总是会触发编辑器，让你在合并中添加细节。“git merge $tag“用于合并带注解的标记，在交互式编辑会话期间总是打开编辑器。v1.7.10系列引入了一个环境变量GIT_MERGE_AUTOEDIT，以帮助较旧的脚本拒绝这种行为，但维护跟踪也应支持它。它还引入了一个环境变量**GIT_MERGE_AUTOEDIT**，以帮助旧脚本 * 拒绝 * 此行为。请参见“Anticipating Git 1.7.10“：最近在一个discussion on the Git mailing list中，Linus承认（我也同意）这是我们在Git早期历史上犯的设计错误之一。在1.7.10及以后版本中，在交互会话中运行的git merge命令（即它的标准输入和标准输出都连接到终端）会在创建提交之前打开一个编辑器来记录合并结果，给予用户一个解释合并的机会，就像用户在解决冲突合并后运行的git commit命令一样。莱纳斯说：但我并不真正关心它实际上是如何工作的-我的主要问题是git太容易产生错误的合并消息。我认为其中一部分是一个更简单的白痴：**默认情况下，我们甚至不会为“git merge”启动编辑器，但我们会为“git commit“启动编辑器。这是一个设计上的错误，这意味着如果你想在合并中添加一个注解，你必须做额外的工作。请注意，在Git 2.17（Q2 2018）之前，“git rebase -p“损坏了合并提交的日志消息，现在已修复。参见Gregory Herrero (``)的commit ed5144d（2018年2月8日）。建议人：Vegard Nossum ( vegard )和Quentin Casasnovas ( casasnovas )中的一个或多个。（由Junio C Hamano -- gitster --合并至commit 8b49408，2018年2月27日）
git merge
git merge $tag
GIT_MERGE_AUTOEDIT
git commit
git rebase -p
vegard
casasnovas
gitster
rebase -p
既然（“rebase -p：修复了调用git merge时引用的问题“，2018年1月，Git 2.16.0-rc 2），使用执行'git rev-parse --sq-quote'的子shell将正在重定基的合并提交的提交消息传递给合并命令。此子shell需要用双引号括起来，以便为git merge命令保留换行符。在此修补程序之前，以下合并消息：
git rev-parse --sq-quote
"Merge mybranch into mynewbranch Awesome commit."
变为：
在rebase -p之后。在Git 2.23（Q2 2019）中，在“git rebase --rebase-merges”期间的一条“merge -c”指令应该给予用户一个编辑日志消息的机会，即使没有必要创建新的合并并替换现有的合并（即快进），但实际上并没有。已被纠正。参见Phillip Wood ( phillipwood )（2019年5月2日）。（2019年6月13日，由Junio C Hamano -- gitster --在commit c510261中合并）
git rebase --rebase-merges
merge -c
phillipwood
wtzytmuj3#
另一个仅使用基本命令的好答案--由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 rebase -p -i HEAD^^^^
mnowg1ta4#
对于当前的Git版本（2020+），只需执行git rebase -i -r <parent>，然后在编辑器中将merge -C替换为merge -c。这将在重定基时在编辑器中打开合并提交的消息，您可以在那里更改它（感谢VonC对hint的支持）。
git rebase -i -r <parent>
merge -C
7qhs6swi5#
从2021年起更新，-p已弃用。请改用--rebase-merges。
wmvff8tz6#
使用--rebase-merges（或缩短的-r）标志：
-r
git rebase -i -r HEAD~5
然后将提交更改旁边的“pick”文本更改为“edit”或“reword”：
pick <commit-hash-to-leave> <message> edit <commit-hash-to-change> <message>
--rebase-merges（或缩短的-r）标志替换了已弃用的--preserve-merges（或简称为-p）文件：https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt--r
hgb9j2n67#
git merge --edit即使在非交互式合并的情况下，也允许您给予注解。git merge --edit --no-ff在遵循git流程时，如果你在开发分支上进行rebased，并且没有快进的情况下合并到其中，那么git merge --edit --no-ff会很有用。
git merge --edit
git merge --edit --no-ff
vcirk6k68#
git rebase -i HEAD~5命令弹出编辑器。（在本例中是五个）。第一列包含每次提交的pick。只需在该编辑器中将pick替换为reword，然后保存并关闭编辑器。然后git会弹出编辑器，让你在每次提交时修改pick，并编辑提交消息。
pick
reword
8条答案
按热度按时间wooyq4lh1#
如果你在
git rebase -i命令中添加了--preserve-merges选项（或者它的同义词，-p），那么git会尝试在重定基时保留合并，而不是线性化历史记录，并且你也可以修改合并提交：注：自git v2.22（https://www.infoq.com/news/2019/07/git-2-22-rebase-merges/）起，
--perserve-merges已被弃用，取而代之的是--rebase-merges。pexxcrt22#
请注意，starting git1.7.9.6（和git1.7.10+），
git merge本身总是会触发编辑器，让你在合并中添加细节。“
git merge $tag“用于合并带注解的标记，在交互式编辑会话期间总是打开编辑器。v1.7.10系列引入了一个环境变量GIT_MERGE_AUTOEDIT，以帮助较旧的脚本拒绝这种行为，但维护跟踪也应支持它。它还引入了一个环境变量**
GIT_MERGE_AUTOEDIT**，以帮助旧脚本 * 拒绝 * 此行为。请参见“Anticipating Git 1.7.10“：
最近在一个discussion on the Git mailing list中，Linus承认（我也同意）这是我们在Git早期历史上犯的设计错误之一。
在1.7.10及以后版本中，在交互会话中运行的git merge命令（即它的标准输入和标准输出都连接到终端）会在创建提交之前打开一个编辑器来记录合并结果，给予用户一个解释合并的机会，就像用户在解决冲突合并后运行的git commit命令一样。
莱纳斯说：
但我并不真正关心它实际上是如何工作的-我的主要问题是git太容易产生错误的合并消息。
我认为其中一部分是一个更简单的白痴：**默认情况下，我们甚至不会为“git merge”启动编辑器，但我们会为“
git commit“启动编辑器。这是一个设计上的错误，这意味着如果你想在合并中添加一个注解，你必须做额外的工作。
请注意，在Git 2.17（Q2 2018）之前，“
git rebase -p“损坏了合并提交的日志消息，现在已修复。参见Gregory Herrero (``)的commit ed5144d（2018年2月8日）。
建议人：Vegard Nossum (
vegard)和Quentin Casasnovas (casasnovas)中的一个或多个。（由Junio C Hamano --
gitster--合并至commit 8b49408，2018年2月27日）rebase -p：修复了调用git merge时不正确提交消息。既然（“
rebase -p：修复了调用git merge时引用的问题“，2018年1月，Git 2.16.0-rc 2），使用执行'git rev-parse --sq-quote'的子shell将正在重定基的合并提交的提交消息传递给合并命令。此子shell需要用双引号括起来，以便为
git merge命令保留换行符。在此修补程序之前，以下合并消息：
变为：
在
rebase -p之后。在Git 2.23（Q2 2019）中，在“
git rebase --rebase-merges”期间的一条“merge -c”指令应该给予用户一个编辑日志消息的机会，即使没有必要创建新的合并并替换现有的合并（即快进），但实际上并没有。已被纠正。
参见Phillip Wood (
phillipwood)（2019年5月2日）。（2019年6月13日，由Junio C Hamano --
gitster--在commit c510261中合并）wtzytmuj3#
另一个仅使用基本命令的好答案--由knittl https://stackoverflow.com/a/7599522/94687提供：
或者更好（更正确）的最终重定基底命令：
顺便说一句，使用原始命令可能有一个很好的“特性”，即不会消耗太多CPU，并且让你等待未知的时间，直到Git完成对需要重定基的提交列表的思考（在
git rebase -p -i HEAD^^^^的情况下，这样的命令将导致一个只有4个最后提交的列表，而在我的情况下，最后一个提交大约花了50秒！）。mnowg1ta4#
对于当前的Git版本（2020+），只需执行
git rebase -i -r <parent>，然后在编辑器中将merge -C替换为merge -c。这将在重定基时在编辑器中打开合并提交的消息，您可以在那里更改它（感谢VonC对hint的支持）。7qhs6swi5#
从2021年起更新，
-p已弃用。请改用
--rebase-merges。wmvff8tz6#
使用
--rebase-merges（或缩短的-r）标志：然后将提交更改旁边的“pick”文本更改为“edit”或“reword”：
--rebase-merges（或缩短的-r）标志替换了已弃用的--preserve-merges（或简称为-p）文件：https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt--r
hgb9j2n67#
git merge --edit即使在非交互式合并的情况下，也允许您给予注解。
git merge --edit --no-ff在遵循git流程时，如果你在开发分支上进行rebased，并且没有快进的情况下合并到其中，那么git merge --edit --no-ff会很有用。vcirk6k68#
git rebase -i HEAD~5命令弹出编辑器。（在本例中是五个）。第一列包含每次提交的pick。只需在该编辑器中将pick替换为reword，然后保存并关闭编辑器。然后git会弹出编辑器，让你在每次提交时修改pick，并编辑提交消息。