当前位置：文江博客话题详情

Git COMMIT git-amend

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

发布于 2024-12-02 14:31:32 字数 182 浏览 3 评论 0 原文

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

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

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

ぶ宁プ宁ぶ 2024-12-09 14:31:32

如果将 --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/）。

If you add the --preserve-merges option (or its synonym, -p) to the git rebase -i command 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:

git rebase -i -p HEAD~5

Note. --perserve-merges has been deprecated in favour of --rebase-merges as of git v2.22 (https://www.infoq.com/news/2019/07/git-2-22-rebase-merges/).

回复收藏 0 原文

挽袖吟 2024-12-09 14:31:32

请注意，启动 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”会损坏合并提交的日志消息，现已修复。

请参阅 commit ed5144d（2018 年 2 月 8 日），作者：格雷戈里·埃雷罗(``)。
建议者：Vegard Nossum (vegard) 和昆汀·卡萨诺瓦斯 (casasnovas)。
^{（由 Junio C Hamano -- gitster -- 合并于提交8b49408，2018 年 2 月 27 日）}

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 命令。

在此补丁之前，以下合并消息：
“将 mybranch 合并到 mynewbranch

很棒的承诺。”
变成：
“将 mybranch 合并到 mynewbranch 很棒的提交。”
在rebase -p之后。

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

请参阅提交 6df8df0（2019 年 5 月 2 日），作者：菲利普·伍德（菲利普伍德）。
^{（由 Junio C Hamano -- gitster -- 合并于提交c510261，2019 年 6 月 13 日）}

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

"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.

It also introduces an environment variable GIT_MERGE_AUTOEDIT to help older scripts decline this behavior.

See "Anticipating 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.

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.

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

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)}

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 merge command.

Before this patch, following merge message:
"Merge mybranch into mynewbranch

Awesome commit."
becomes:
"Merge mybranch into mynewbranch Awesome commit."
after a 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.

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

回复收藏 0 原文

浅唱々樱花落 2024-12-09 14:31:32

仅使用原始命令的另一个很好的答案 - 作者：knittl https://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 秒！）。

Another nice answer using only primitive commands -- by 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:

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!).

回复收藏 0 原文

谁许谁一生繁华 2024-12-09 14:31:32

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

回复收藏 0 原文

给我一枪 2024-12-09 14:31:32

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

git merge --edit --no-ff
如果您遵循 git flow 并在开发分支上重新建立基础并在没有快进的情况下合并到其中，这会很有用。

回复收藏 0 原文

一腔孤↑勇 2024-12-09 14:31:32

从 2021 年开始更新，-p 已弃用。

使用 --rebase-merges 代替。

回复收藏 0 原文

小帐篷 2024-12-09 14:31:32

使用 --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（或缩短的-r）标志取代了已弃用的
--preserve-merges （或缩写的 -p）

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

Use the --rebase-merges (or the shortened -r) flag:

git rebase -i -r HEAD~5

Then change the 'pick' text to 'edit' or 'reword' next to the commit to change:

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

The --rebase-merges (or the shortened -r) flag replaces the deprecated
--preserve-merges (or the shortened -p)

Documentation: https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt--r

回复收藏 0 原文

总以为 2024-12-09 14:31:32

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