我正在同时研究两个功能，"feature1"是"feature2"的基础。我为他们创建了两个分支;当我在功能1上工作时，我提交到"功能1"分支;当我在 feature2 上工作时，我会提交到"feature2"分支中，并定期将"feature2"重新定位在"feature1"之上：
git checkout feature2
git rebase feature1
... work ...
git commit ...
所以，在某个时刻，我有这样的结构：
feature1: A -> B -> C
feature2: A -> B -> C -> P -> Q -> R
至此，我已经完成了功能1;我想将 A、B 和 C 压缩为一个提交 D，并在功能1的这种新状态上重新设置功能2的基数：
feature1: D
feature2: D -> P' -> Q' -> R'
头脑简单，我在功能1上运行交互式变基，成功地将A，B和C压缩为D，并尝试变基功能2
git checkout feature2
git rebase feature1
现在，git 将 D 拉入 feature2 分支，并尝试在其上重新应用 A、B、C、P、Q 和 R。当然，A、B 和 C 中的更新已经被 D 应用了，因此它们会导致合并冲突。
我通过反复试验得出，当在重新应用 A、B 和 C 时报告合并冲突时，我只需要运行
git rebase --skip
我最终得到了我需要的结果。但是，首先，如果您还不知道，这并不明显，其次，很容易忽略和跳过潜在的真正合并冲突。后者应该不太可能，但如果发生这种情况，那就相当糟糕了，因为您会永远丢失相应的更新。
所以，我的问题是：有没有更好的方法将你的分支重新定位在一个分支上，其中一些提交最近被压缩成一个分支？
我喜欢使用 --onto 选项来变基和 @n reflog 提交命名来解决我在这里的问题，这经常出现在与非 git VCS 交互时，或者几乎任何时候您是几个相互依赖但未发布的本地分支。
在第一次变基之后：（您正在压缩提交，但它几乎可以是任何变基）
git rebase -i master feature1
接着进行第二次变基：
git rebase --onto feature1 feature1@1 feature2
或（"长手"）
git checkout feature2
git rebase --onto feature1 feature1@1
也就是说，在 feature2 中获取以前版本的 feature1 中没有的提交，并在当前版本的 feature1 之上重播它们。
由于变基会弄乱 git 的合并历史想法，git 无法自动判断您要做什么。与其处理冲突并为每个不需要的提交发出rebase --skip，不如使用 git rebase -i feature1 作为最终的变基命令，只需从列表中删除未压缩的提交即可。