3

我正在同时开发两个功能，“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 的新状态重新设置 feature2 ：

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

头脑简单，我在 feature1 上运行交互式 rebase，成功将 A、B 和 C 压缩为 D，并尝试 rebase 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

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

所以，我的问题是：有没有更好的方法来将你的分支重新建立在一个分支上，其中一些提交最近被压缩成一个？

4

2 回答 2

2

由于 rebase 与 git 合并历史的想法相混淆，git 无法自动告诉您要做什么。与其处理冲突并rebase --skip为每个不需要的提交发出一个，git rebase -i feature1不如将其用作您的最终变基命令，并简单地从列表中删除未压缩的提交。

于 2013-09-17T10:09:01.853 回答
2

我喜欢使用 --onto 选项来 rebase 和 @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 之上重播它们。

于 2013-09-18T18:52:41.583 回答