如何轻松撤消git重基?冗长的手动方法是:

签出两个分支的提交父级创建并签出临时分支手工挑选所有提交重置故障的重基分支以指向临时分支

在我目前的情况下,这是可行的,因为我可以很容易地发现两个分支的提交(一个是我的东西,另一个是同事的东西)。然而,我的方法给我的印象是次优且容易出错(假设我刚刚用自己的两个分支重新建立了基础)。

澄清:我所说的是一个重基,在重基过程中,多次提交被重复,而不仅仅是一次。


当前回答

实际上,在执行任何非平凡操作之前,我在分支上放置了一个备份标记(大多数重基是微不足道的,但如果它看起来很复杂,我会这样做)。

然后,恢复就像git reset一样简单——hard BACKUP。

其他回答

按照@Allan和@Zearin的解决方案,我希望我可以简单地发表评论,但我没有足够的声誉,所以我使用了以下命令:

我不得不简单地执行gitrebase-i-art(不使用-i),而不是执行gitrebase-i-art。

同时使用-i和--abort会导致Git显示用法/选项列表。

因此,我以前和现在使用此解决方案的分支状态是:

matbhz@myPc /my/project/environment (branch-123|REBASE-i)
$ git rebase --abort

matbhz@myPc /my/project/environment (branch-123)
$

如果您在分支机构,可以使用:

git reset --hard @{1}

HEAD不仅有一个引用日志(通过git reflog获得),每个分支也有reflog(通过gitreflog<branch>获得)。所以,如果您在master上,那么git-relog master将列出该分支的所有更改。您可以通过master@{1}、master@{2}等引用这些更改。

gitrebase通常会多次更改HEAD,但当前分支只会更新一次。

@{1} 只是当前分支的快捷方式,因此如果您在master上,它等于master@{1}。

git reset——如果在交互式重基过程中使用git rese,硬ORIG_HEAD将无法工作。

我尝试了重置和刷新的所有建议,但没有成功。恢复IntelliJ的本地历史记录解决了文件丢失的问题

使用reflog对我不起作用。

对我有用的东西与这里描述的相似。在.git/logs/refs中打开以重新基于分支命名的文件,找到包含“rebase finsihed”的行,类似于:

5fce6b51 88552c8f Kris Leech <me@example.com> 1329744625 +0000  rebase finished: refs/heads/integrate onto 9e460878

签出行中列出的第二个提交。

git checkout 88552c8f

一旦确认这包含了我丢失的变化,我就分支起来,松了一口气。

git log
git checkout -b lost_changes

如果你不想硬复位。。。

您可以从reflog签出提交,然后将其保存为新分支:

git reflog

在开始重定基础之前找到提交。您可能需要进一步向下滚动才能找到它(按Enter键或PageDown键)。记下HEAD编号并更换57:

git checkout HEAD@{57}

检查分支/提交,如果正确,则使用此HEAD创建一个新分支:

git checkout -b new_branch_name