我正在同时处理两个功能,“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
我最终得到了我需要的结果。但是,首先,如果您还不知道,这一点并不明显,其次,很容易忽视并跳过潜在的真正合并冲突。后者应该不太可能,但是如果它发生了,那就相当糟糕了,因为你失去了相应的更新。
所以,我的问题是:是否有更好的方法可以在一个分支上重新分支你的分支,其中一些承诺最近被压缩成一个?
答案 0 :(得分:2)
由于使用git关于合并历史的想法来改变混乱,git无法自动判断出你想要做什么。不是处理冲突并为每个不需要的提交发出rebase --skip
,而是使用git rebase -i feature1
作为最终的rebase命令,只需从列表中删除未撤消的提交。
答案 1 :(得分: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之上重播它们。