在另一个rebase合并提交的分支上进行Git rebase

3

我正在同时开发两个功能,"feature1" 是 "feature2" 的基础。我为它们创建了两个分支; 当我在开发 "feature1" 时,我提交到 "feature1" 分支;当我在开发 "feature2" 时,我提交到 "feature2" 分支,并定期将 "feature2" 在 "feature1" 的基础上进行变基(rebase):

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,并在此基础上重新设置feature2的状态:

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

简单地说,我在 feature1 上运行了交互式变基,成功地将 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

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

所以,我的问题是:是否有更好的方法在最近有一些提交被压缩成一个分支的情况下重新设置你的分支?

2个回答

2
我喜欢使用--onto选项进行变基,并使用@n reflog提交名称来解决我的问题。在与非Git VCS交互或任何时候有多个本地分支相互依存但未发布的情况下,这种问题经常出现。
第一次变基后:(您正在压缩提交,但几乎可以是任何变基)
git rebase -i master feature1

接下来进行第二次变基:

git rebase --onto feature1 feature1@1 feature2

OR ("long hand")

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

这句话的意思是,取feature2中与之前版本的feature1不同的提交,并将它们重新应用在当前版本的feature1上。


1
这似乎比之前的答案更“简洁”,但需要一些努力才能理解。 - crosser

2

由于变基会影响git的合并历史概念,因此git无法自动判断你的意图。不要处理冲突并对每个不需要的提交发出rebase --skip,而是将git rebase -i feature1用作最终变基命令,并从列表中简单地删除未压缩的提交。


@Boyd的建议可以达到相同的效果,在编辑提交列表时减少出错的机会,因此我更喜欢它。但还是谢谢,现在我又了解了git的另一件事! - crosser

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接