Git 重新设置还原合并分支的基

背景：我最近将一个相当大的主题分支合并到了

master

。几天后，我发现这个主题分支包含bug。所以我

git revert-m1

ed了它

问题：现在，我想检查主题分支，并根据当前的

主机重新设置其基础，以便1）修复错误，2）（再次）将已修复的主题分支与主机合并。创建新分支时，
fixedtopic
是最简单的部分，但每次我都这么做

git checkout fixedtopic
git rebase master

git决定不愿意重播旧的提交，因为它们已经合并到
master
。相反，它只是做了一个快速的重新基址

问题：如何使用
rebase
强制将提交重播到
fixedtopic
？我可以吗？我不想用樱桃镐，因为它有点麻烦

附加：


git reset
ing合并提交它不是一个选项，因为我已将主机推到上游
我不希望从
master
创建一个新分支，并恢复我的还原。这样做的原因是，我想使用交互式重基重写主题分支的一些历史记录
下面是该场景的github要点：请注意，我希望e8df5ec和ee16464应用于
master
（或基于
master
的分支）
您需要使用
--on
来防止Git表单试图自行确定适当的未合并提交

例如（主题分支已签出）：

git-rebase——在主服务器上

对于
，您需要主题分支的
git merge base
，以及还原的合并之前的commit on master

编辑

再次阅读您的情况，如果您将主题分支快进到还原合并的点，然后还原还原并从该点修复主题分支，可能会更好。这样，您就不会重复原始主题分支中的所有提交，而是在master的最终历史记录中使用新ID。无论您做什么，最终都会出现一个包含“do、undo、redo”的历史记录，但这种方式可能会被认为是一个更干净的历史记录。
实现这一点的一种方法是以交互方式重新设置主题分支的基础，并在分支出master后重新编写第一次提交（例如，如果分支中有10次提交，则为
git-rebase-i HEAD~10
）。这将重写主题分支内所有提交的sha。因此，您可以使用
git-rebase-master
以通常的方式重新设置基础，最有效的方法是签出一个新分支，然后通过还原恢复来重新恢复以前的工作分支

我尝试过的所有其他方法都过于复杂和/或不起作用。
文档（git help rebase）建议“git rebase--force rebase”可以做到这一点，但（git 1.9.1）不能做到。文档还建议“git rebase-i--no ff”等同于该命令，但事实并非如此：它确实有效

克隆了要点后，命令：

  git checkout topic
  git rebase -i --no-ff --onto master 7b3af topic

生成所需的结果，新版本的“第三个”和“第四个”将提交到master上，并且
topic
指向新版本的“第四个”。在第二个命令中，SHA
7b3af
是“第二个”提交，即
topic
的分支点。
对于
git merge
（即不是最初要求的
git rebase
），如所示（请参阅“反向提交”部分）：

解决此问题的最佳方法是取消还原原始合并，因为现在您希望引入已还原的更改，然后创建新的合并提交：

$git revert^M


$git合并主题


图142。重新合并还原的合并后的历史记录

使用Git2.22

，jurglic建议的解决方案似乎不再有效

让我们从状态开始，以确保我们谈论的是同一件事：

P---o---o---M---o---o---o---o---o---W---o---o---master
 \         /     \                /
  A---B---C       D (revert A-B-C)

我用

a-B-C

提交创建了一个dev分支，它被合并到

M

，但我们立即注意到有一个错误，所以它被还原到

W

。我想在

master

上重新设置

A-B-C

的基址，并在再次合并之前解决该问题

以下是我所做的：

git checkout C          (detached HEAD) 
git checkout -b redo
git rebase -i master

但在这一点上，git只提供了以下内容：

noop

# Rebase A..C onto X (1 command)

这意味着它发现我试图重新应用完全相同的提交，而它们已经被合并

为了解决这个问题，jurglic曾建议修改

A

的提交消息，但似乎

Git2.22

足够聪明，能够解决这个问题，并且仍然向我提供完全相同的

noop

。我尝试了其他解决方案，使用了

--force-rebase

和/或

--no-ff

，但我一直回到

noop

最后，我使用了一条简单的捷径，在

rebase-I

选择编辑器中手动输入，并将

noop

替换为：

pick A
pick B
pick C

或者，如果要保存更多击键，请执行以下操作：

p A
p B
p C

---

这终于奏效了。

查尔斯，谢谢你的回答。即使使用

--on

，我仍然无法完成这项工作。我用Github的要点更新了我的问题，以获得一个我所处情况的工作示例。我和一位同事最近在一个功能分支中遇到了同样的问题。我们的解决方案与公认的解决方案大致相同，但我们选择将分支中的所有提交压缩为单个提交。这在功能上等同于还原还原，最终更简单。对于未来面临此问题的人，请注意。

git revert

和

git rebase

都引用了一个[revert-a-fault-merge How To][1]，其中描述了如何处理此问题，以帮助澄清：“重写fi

p A
p B
p C