我想压制一些比"冲突"合并更早的提交。 例如：
main branch: A--B--C--D--G--H
dev branch: -E--F----/
H 是我目前的头，G 是冲突合并(所以我手动解决冲突的合并)，我想压制 C 和 D - 但如果我尝试这样做，我会收到变基冲突，这是由于 G 是冲突合并。
无论如何，我可以挤压 C 和 D 吗，如果是，如何？我会对一种不必再次手动合并某些内容的解决方案感兴趣。
附加信息：将所有提交保留在"pick"上时，git rebase -i B甚至不起作用 - 这应该什么都不做，对吧？
不要为此使用 rebase，rebase 可以为您挤压，但它是为比像这样的仅限祖先重写更重的提升而构建的，它做了大量(缓慢的)准备工作，以实现您在此过程中喜欢的任何更改。
git replace --graft G B F # (put usable references to those commits here of course)
git filter-branch
而且你已经实现了变基后的一切，速度要快得多。
第一：默认情况下，git rebase完全忽略合并提交。您必须指定-r | --rebase-merges才能使git rebase"知道"您的合并操作。
结合-i：您将看到音序器脚本更加精细，并允许您描述要采取的重播合并的操作。
秒：在您描述的场景中，要合并的提交内容将与原始提交的内容相同，因此"解决冲突"等同于："重用与G完全相同的内容"。
如果在合并时遇到冲突：尝试运行
git restore --staged --source G -- .
# or using shorthands :
git restore -S -s G -- .
如果需要从索引中的文件中清除"冲突"标志，则可能需要事先运行git reset .。
如果您的本地 git 没有git restore(此命令是最近在 git 2.27 中添加的 - 2020 年 6 月)：try
git read-tree G
这应该将G的内容放在索引中。