我正在同时处理两个功能,“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,并尝试 rebase feature2
git checkout feature2
git rebase feature1
现在,git 将 D pull 入 feature2 分支并尝试在其上重新应用 A、B、C、P、Q 和 R。当然,A、B、C 中的更新已经被 D 应用,因此它们会导致 merge 冲突。
我通过反复试验发现,在重新应用A、B、C时报告 merge 冲突时,我只需要运行
git rebase --skip
我最终得到了我需要的结果。但是,首先,如果您不知道,这并不明显,其次,很容易忽略和跳过潜在的真正 merge 冲突。后者应该不太可能发生,但如果发生了,那就很糟糕了,因为您永远失去了相应的更新。
所以,我的问题是:是否有更好的方法将您的分支重新定位到一个分支,其中一些提交最近被压缩成一个?
最佳答案
我喜欢使用 --onto 选项来 rebase 和 @n reflog 提交命名来解决我这里的问题,这经常出现在与非 git VCS 交互时,或者几乎任何时候你是几个相互依赖的本地分支但未发表。
在你第一次 rebase 之后:(你正在压缩提交,但它几乎可以是任何 rebase )
git rebase -i master feature1
用第二个 rebase 跟进它:
git rebase --onto feature1 feature1@1 feature2
或(“长手”)
git checkout feature2
git rebase --onto feature1 feature1@1
也就是说,获取 feature2 中不在先前版本的 feature1 中的提交,并在当前版本的 feature1 之上重放它们。
关于Git rebase 在一个分支上,该分支具有由另一个 rebase 组合的提交,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/18846696/