1

目标

我想使用 rebase 修改最近的提交。神奇的命令是git rebase -i

假设您正在尝试删除提交问题

  • 首先，找出该提交有多远（大约）。然后做：
    • git rebase -i HEAD~10


-来源：
Greg Hewgill对一个不太复杂的 git 问题的回答


问题

效果很好，除非你最近做了任何 --no-ff 合并

如果你碰巧遵循git flow，你会一直做 --no-ff 合并

  • 检查下面的“来源”部分以获取有关rebase -i 炸毁 --no-ff 合并的方式和原因的示例
  • 现在，请相信我（或自己尝试）：它不漂亮


实际问题

如果我们查看此页面，我们会看到一个--preserve-merges（或简单的-p）选项，我们可以尝试将其替换-i为

问题是，如果我们这样做，我们将不再收到-i以前那种漂亮的弹出窗口
-> 可以选择“编辑此提交，挤压那个”等。-
> 所以，我们可以' t 达到我们最初的目标：使用 rebase 修改/删除一些最近的提交 :(

那么我们该怎么办？



来源

问题部分：

4

2 回答 2

1

上面使用-pand-i是正确的 - 但是我想指出你不需要使用交互式更多来摆脱提交。您可以使用--onto来明确说明您希望您的基地在哪里。假设你想摆脱 HEAD~10，......

git rebase --onto HEAD~11 HEAD~9 HEAD

这就是说，接受任何在中HEAD，但**不是* 在 中的提交HEAD~9，并将它们应用到HEAD~11. 那意味着它会跳过HEAD~10。上面的解决方案工作得很好，但有时，为了摆脱更大的历史记录，你可能想要使用--onto. 请记住，与 的情况一样-p，您也可以将交互模式与--onto.

关于非快进合并和变基，看看我给另一个问题的这个答案。它主要解释了 的用法--onto，但如果你通读，你会发现关于 --no-ff 合并和变基的解释。

于 2013-04-21T11:44:49.947 回答
1

-p并且-i不是相互排斥的 - 您可以同时使用两者。但是，当你这样做时要非常小心——改变提交的顺序是一个坏主意。您也不应该尝试以这种方式删除合并提交；很容易使事情进入不正确的状态。

git rebase -p -i HEAD~10
于 2013-04-21T03:07:30.933 回答