Question

我正在同时处理两个功能，“feature1”是“feature2”的基础。我为他们创建了两个分支;当我在feature1上工作时，我会进入“feature1”分支;当我在feature2上工作时，我会进入“feature2”分支，并定期在“feature1”之上修改“feature2”：

git checkout feature2
git rebase feature1
... work ...
git commit ...

所以，在某个时刻，我有这个结构：

feature1: A -> B -> C
feature2: A -> B -> C -> P -> Q -> R

此时，我完成了feature1;我想将A，B和C压缩成单个提交D，并在feature1的这个新状态下使用rebase feature2：

feature1: D
feature2: D -> P' -> Q' -> R'

简单明了，我在feature1上运行交互式rebase，成功地将A，B和C压缩成D，并尝试重新定义feature2

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

我最终得到了我需要的结果。但是，首先，如果您还不知道，这一点并不明显，其次，很容易忽视并跳过潜在的真正合并冲突。后者应该不太可能，但是如果它发生了，那就相当糟糕了，因为你失去了相应的更新。

所以，我的问题是：是否有更好的方法可以在一个分支上重新分支你的分支，其中一些承诺最近被压缩成一个？

Answer 1

由于使用git关于合并历史的想法来改变混乱，git无法自动判断出你想要做什么。不是处理冲突并为每个不需要的提交发出rebase --skip，而是使用git rebase -i feature1作为最终的rebase命令，只需从列表中删除未撤消的提交。

Answer 2

我喜欢使用--onto选项进行rebase和@n reflog提交命名来解决我的问题，这通常在与非git VCS交互时出现，或者几乎任何时候你都是相互依赖的几个本地分支但没有公布。

在你的第一次变基之后:(你正在压缩提交，但它几乎可以任何变种）

git rebase -i master feature1

跟进第二个rebase：

git rebase --onto feature1 feature1@1 feature2

OR（“长手”）

git checkout feature2
git rebase --onto feature1 feature1@1

其中说，在feature2中提交不在先前版本的feature1中的提交，并在当前版本的feature1之上重播它们。