这就是我面对的情况，以及我是如何解决它的。

[branch-a]

[Hundreds of commits] -> [R] -> [I]

这里R是我需要删除的提交，I是在R之后的一个单独的提交

我做了一个回复提交，并把它们压在一起

git revert [commit id of R]
git rebase -i HEAD~3

在交互重基期间，压缩最后2次提交。

到目前为止，所有的答案都没有解决后面的问题:

当有数百个修订时，是否有一种有效的方法 在要删除的那个之后?

以下是步骤，但为了参考，让我们假设历史记录如下:

[master] -> [hundreds-of-commits-including-merges] -> [C] -> [R] -> [B]

C: 只在要删除的提交之后提交(干净)

接待员: 要删除的提交

B: 在要删除的提交之前提交(base)

由于“数百个修订”的限制，我假设以下先决条件:

there is some embarrassing commit that you wish never existed there are ZERO subsequent commits that actually depend on that embarassing commit (zero conflicts on revert) you don't care that you will be listed as the 'Committer' of the hundreds of intervening commits ('Author' will be preserved) you have never shared the repository or you actually have enough influence over all the people who have ever cloned history with that commit in it to convince them to use your new history and you don't care about rewriting history

这是一组非常严格的约束条件，但在这种情况下，有一个有趣的答案。

以下是步骤:

git分支B git分支remove-me R Git分支保存 Git rebase -preserve-merges - to base remove-me

如果真的没有冲突，那么这应该继续进行，没有进一步的中断。如果有冲突，你可以解决它们，然后重新开始——继续，或者决定忍受尴尬，重新开始——中止。

现在你应该在master上不再有commit R了。save分支指向您之前的位置，以防您想要调和。

如何安排其他人转移到您的新历史记录取决于您自己。你将需要熟悉隐藏，重置——困难，和樱桃选择。你可以删除基础，删除我，保存分支

如前所述，git-rebase(1)是您的朋友。假设提交在你的主分支中，你会这样做:

git rebase --onto master~3 master~2 master

之前:

1---2---3---4---5  master

后:

1---2---4'---5' master

从git-rebase (1):

提交的范围也可以是 删除与rebase。如果我们有 以下情况: E - F - G - H - I - J局部药 然后命令 git rebase - to topicA~5 topicA~3 topicA 会导致移除 提交F和G: E - H”——我——J的局部药 如果F和G在某些方面有缺陷，这是有用的 或者不应该是topicA的一部分。 注意参数to -onto和 参数可以为任意值 commit-ish有效。

收音机和kareem的回答对我没有任何帮助(只有消息“当前分支是最新的。”出现)。这可能是因为'^'符号在Windows控制台中不起作用。但是，根据这条注释，将'^'替换为'~1'可以解决这个问题。

git rebase --onto <commit-id>^ <commit-id>

我也遇到了类似的情况。使用下面的命令使用交互式rebase，并在选择时，删除第三次提交。

git rebase -i remote/branch

下面是一种非交互式删除特定<commit-id>的方法，只知道你想删除的<commit-id>:

git rebase --onto <commit-id>^ <commit-id> HEAD