Git rebase 失败，因为： Commit xxxx 是合并，但没有给出 -m 选项

Question

我有一个功能分支：

feature

假设有 10 次提交

然后前段时间我开始在上面做实验，但想保留当前的功能以防万一，所以我开始了一个新的分支：

feature-experiment

然后又进行了 10 次提交

今天我决定将

merge

feature-experiment

变成

feature

然后删除

feature-experiment

。我解决了一些合并冲突。

然后，我的 20 个提交都使用相同的名称并以

WIP

结尾（正在进行中），非常丑陋，所以我决定

git rebase -p -i HEAD~22

我将

pick

更改为

s

以将它们全部压缩到此功能的最旧提交中，但我遇到了一些合并冲突（与以前相同）。我解决了它们然后

git add -A && git commit

git rebase --continue

但现在我收到以下错误：

error: Commit asd123qsd is a merge but no -m     option was given.
fatal: cherry-pick failed
Could not pick asd123qsd 

这是最后一次提交（合并）

我又试了一次，但这次我没有将这个特定提交的

pick

更改为

s

，但得到了同样的错误。

我怎样才能进行这个可怕的变基？

我在想，作为一个可能的解决方案，我可以修改最后一次提交以添加 -m ，但是我该怎么做以及如何使用这个 -m 命令？还有其他选择吗

Answer 1

问题可能出在这里：

git rebase -p -i HEAD~22

-p

选项在git文档中被描述为

--preserve-merges

的简短版本：

-p

--保留合并

重新创建合并提交，而不是通过重播来展平历史记录 提交合并提交介绍。合并冲突解决方案或 不会保留对合并提交的手动修改。

这在内部使用了 --interactive 机制，但是将其组合起来 明确使用 --interactive 选项通常不是一个好主意 除非你知道自己在做什么（参见下面的错误）。

由于您试图在此处压缩提交，因此保留合并提交几乎肯定不是您想要的。此外，有关将

--preserve-merges

标志与

--interactive

(

-i

) 标志组合的警告可能与此相关。

老实说，使用变基来做这样的挤压可能会带来比你在这里需要的复杂得多的复杂性。如果您想要的只是将该分支的所有更改压缩到单个提交中，您可以这样做：

git checkout feature
git reset --soft <base of feature branch>

此时，功能分支中的所有更改都应该暂存，并且功能分支应该位于基础提交处。现在，您可以简单地运行

git commit

来创建一个新的提交，其中包含功能分支中的所有更改，这基本上相当于挤压。

Answer 2

我收到以下错误...

错误消息会更清晰（因为您保留了合并提交）：

'

pick

' 不进行合并提交。
如果您想重播合并，请在提交上使用“merge -C”。

使用 Git 2.46（2024 年第 3 季度），第 15 批，当用户添加“

git rebase -i

”^(man) 指令来选择合并提交时，错误体验并不令人愉快。
现在，在解析

todo

列表的过程中，可以更早地捕获此类错误。

请参阅 commit 4c063c8、commit 0c26738（2024 年 5 月 30 日），作者：Phillip Wood (

phillipwood

)。
（由 Junio C Hamano --

gitster

-- 合并于 commit 83ac567，2024 年 6 月 20 日）

rebase -i

：改进选择合并时的错误消息

^{报道者：Stefan Haller
签字人：Phillip Wood}

接受合并提交的唯一

todo

命令是“

merge

”和“

reset

”。
所有其他命令（如“

pick

”或“

reword

”）在尝试选择合并提交并打印消息时都会失败

error: commit abc123 is a merge but no -m option was given.

随后是有关重新安排命令的提示。
此消息旨在帮助用户选择合并并忘记传递“

-m

”。
对于正在变基的用户来说，该消息令人困惑，因为变基无法挑选合并。

通过检测错误并在解析待办事项列表时打印一些有关如何修复它的建议来改善用户体验，而不是等待“pick”命令失败。
该建议建议使用“

merge

”而不是

exec git cherry-pick -m ...

^(man)，因为假设挑选合并相对较少，并且用户更有可能错误地选择了挑选。

可以通过允许用户将“

-m

”传递给“

pick

”命令来支持择优合并，但这会增加完成一些已经可以通过

实现的事情的复杂性

exec git cherry-pick -m1 abc123