从中间删除git合并

我们使用合并工作流维护分支结构。因此，我们的主分支提交层次结构如下所示

然而，由于我们使用的是Gitlab community edition，它不会挤压合并并重新设置合并的基础，因此有时开发人员会忘记执行其中一项操作，并合并类似于下面所示的提交

我从中恢复的通常方法是将master重置为这些合并之前的最后一个良好提交，然后重播每次合并（在正确重定和挤压之后）以合并它们

更好的方法可能是使用

git-rebase--on

命令在修复错误合并后重播正确合并。然而，我一直无法找到正确的方法来做到这一点。我所做的是：

将主分支重置为最后一次正确合并的提交

在重新基化分支的顶部重新基化错误提交（未压缩重新基化）

在重新基化分支上合并压缩的重新基化提交

对任何其他错误提交重复该过程

最后，以与步骤2-3相同的方式重播所有好的合并

在第5步中，我尝试使用

git-rebase-ip--on

来重播我的好合并，但这似乎可以用父级的顺序来交换提交。有没有人有办法改进我的工作流程，这样我就不必手动重放每一次合并？

git-rebase-ip--on

似乎不完整

应该是：

git rebase -imp --onto <last_good_commit> <first> <yourBranchToReplay>

git-rebase-imp-on

如果您已签出“yourBranchToReplay”，则可以忽略最后一个参数。
但是您不能忽略

，这是要放在

之上的要重播的分支的第一次提交

正如OP所指出的，这一点很重要。

---

我还

@VonC的回答几乎是正确的。我不得不将rebase命令修改为

git rebase-ipm--on

，它在固定合并上正确地重新设置了所有剩余合并的基础。

我可能会做一些类似于您已经建议的事情；以您的第二张图像为例，我将重置为合并绿色分支的位置，然后签出第一个红色分支并重新设置该分支的基础，然后再次合并它，依此类推以下分支。我之所以选择“慢”的方式是因为存在冲突的风险（语义或句法）——我想检查每一步的结果。你有没有考虑过干脆不做这些事情？Git能够很好地处理这种情况，只要您至少尝试遵守纪律，这样它就不会失控，您真的需要修复任何东西吗？我问的原因是，如果你对重基方案很严格，为什么你会有合并，而不仅仅是一个线性历史？如果没有-m标志，它将不会保留合并，并将扁平化提交，这不是我想要的。