我正在处理一个变基清单,做了git add
,进行了更改,然后进行了rebase --continue
。
但是,在此期间,我不小心输入了rebase --abort.
我想继续进行意外中止的重新定位,所以我做了
git reflog
然后
git reset --hard HEAD@{2}
问题是,如果我输入git rebase --continue
时,它表示我没有进行任何基准调整,并且我
have 1 and 10 different commits each, respectively (use "git pull" to merge the remote branch into yours)
无论如何,我是否可以返回并继续进行变基,还是需要从分支中拉出并重做它?
答案 0 :(得分:0)
第一件事:此时,您不是想要进行git pull。即使您做到了,您也可能会康复,但它会带您去错误的方向[1]。
因此,您执行的步骤正确地恢复了上一次尝试重新设置期间已提交的更改-这可能很有用。
但是,这与将git返回到变基状态不同。还有其他事情-例如git正在管理代表原始提交的补丁程序待办事项列表。
据我所知,实际上没有办法重新启动已中止的重新设置基准。但是您可以使用rebase --onto
对其进行近似。
(a)从旧的rebase的尖端(您已重置到的尖端)创建标签
(b)重置回分支在变基之前的位置。 (您可以在引用日志中再次找到它;这是rebase --abort
向您发送邮件的地方。)
(c)现在,假设您有
x -- A -- B -- C -- D <--(branch)
\
x -- x -- o <--(master)
\
A' -- B' <-rebase_tag
其中rebase_tag
是您在旧的重新尝试尝试时创建的标记,因此A'
是A
的重写,B'
是{{ 1}},您仍然需要重写B
和C
。
您要执行的操作是将D
和C
重写到D
上。所以
B'
在这里,git rebase --onto rebase_tag branch~2 branch
可以用任何解析为branch~2
的表达式(在先前的重新尝试中已重写的最后一次原始提交)代替。
当然,如果与原始重新尝试相关的工作很少,或者花费的时间很少,并且没有很多复杂的合并解决方案,那么您可以可以从头开始重新启动。即使这样做,您也可以在解决冲突时使用“旧的重写提交”作为参考。
但是,假设您很清楚如何计算B
参数的表达式,以上可能是“重新启动”基准的最简单方法。
[1]这里要理解的是,某些git命令给出了非常详细的建议。但是该建议是针对常见用例编写的,在这些用例中,您已经完成了某些假定他们通常认为新用户会做的事情。您做的事情与这些假设不符是很好的,但是他们假设任何知道的人都不需要特定的/详细的建议。
所以发生的事情是,您已经做了一些假设之外的事情,因此--onto
建议不适用;如果您遵循它,将会朝错误的方向前进。并不是说您仍然无法恢复-您可以-但这会更加令人困惑。