我现在有一段相当一段历史的git repo。 我试图在早期的提交上做一些改变，发现了奇怪的冲突。
我发现如果我做一个git rebase COMMIT ^并选择其中一个早期的那个，但是然后在列表中我不碰任何东西，比如选择所有提交，它仍然会通过动作，重放所有提交，对我来说无法解释，都失败了。
这怎么可能？如果由于所有提交都被选中而没有更改历史记录，那么它怎么会失败呢？
答案 0 :(得分：3)
一个rebase通过＆＃34;播放＆＃34;每个差异的变化，使新的提交（保留旧的保持不变，但隐藏，并最终到期）。提交回放的方法＆＃34;可以更直接地以git cherry-pick形式提供，因此我将首先对此进行描述。
做一个挑选涉及提取提交中所做的更改。然后，通过使用diff中包含的上下文，可以将生成的diff应用于（＆＃34;修补到＆＃34;）其他（不同）提交。但是，因为提交没有存储作为更改 - each commit is a complete "snapshot" of the source - 一个挑选必须计算提交提供的更改。它通过将提交与其父提交进行比较来实现。
这适用于线性历史记录，但在合并时效果不佳。特别地，根据定义，合并提交具有至少两个父母（与两个以上父母合并是不寻常的，但是git允许它们）。如果提交了两个父母，而没有明显的方法来选择哪个父母在做出差异时要考虑，git cherry-pick只是停止投诉。它使您可以使用-m选项提供您在选择合并提交时所关心的父级。
rebase命令采用不同的方法：默认情况下，它完全消除了合并，希望它们不是必需的。如果合并很重要（显然他们在这里），这将导致樱桃选择失败。
rebase命令确实有-p（又名--preserve-merges）选项。在这种情况下，它会尝试保持合并。在这种特殊情况下，您将提交序列重放到原始基本提交上，保留合并的rebase应该可以正常工作。
有关详细信息，请参阅文档。