【问题标题】:Get back to latest commit after soft reset软重置后返回最新提交
【发布时间】:2019-06-21 15:03:59
【问题描述】:

我知道已经有人问过这个问题,但没有人提供对我有帮助的解决方案。

我使用 GitKraken,它显然没有用于检查历史中较旧的提交的集成功能(我必须进行一些测试,没有进行任何更改)。我现在知道我应该使用git checkout HEAD~n,而是使用了软重置。所以 GitKraken 仍然显示我的更改在那里并且在我重置之后出现。但是我怎样才能回到我最近的提交呢?签出也不行。

我不确定 GitKraken 是否只是显示错误,但 Git 告诉我我重置的提交是当前的 HEAD。似乎是正确的。

有什么方法可以恢复以下提交或将它们设置为 HEAD?

EDIT 重复标签:引用的线程是关于通过检查先前的提交来返回其预期的方式(我没有这样做)。由于我进行了软重置,因此我的主分支的 HEAD 不再是实际的最新提交,而是我将本地存储库重置为的那个。将git reflog 与重置一起使用有助于撤消已完成的操作。

【问题讨论】:

  • 你能解释一下你想做什么吗?目前,这只是您在没有上下文的情况下尝试过的事情的列表。
  • 返回一个比当前 HEAD 更新的提交,因为我对其进行了重置(之后有 5 个)。但 Git 显然没有意识到这一点。当我重置到最新的提交时,它似乎会反转那些所做的实际更改而不是恢复它们......
  • 它可能解决了这个问题,但从我的角度来看,如果没有进一步损坏存储库的风险,这看起来不能满足我的目的。所以我想说我的问题有点不同,尽管解决方案可能是一样的。

标签: git git-reset


【解决方案1】:

从分支的reflog获取它。

git reflog [show] [log-options] []

所以在你的情况下

git reflog branch-to-be-fixed

它会输出分支上之前的操作列表

59a04ab96 待修复分支@{1}:提交:...消息...

574c5ca23 待修复分支@{2}:提交:...消息...

此时,根据消息或哈希在输出中发现您需要的提交,并使用句柄重置为您想要的状态:

git reset --hard branch-to-be-fixed@{1}

【讨论】:

  • git checkout HEAD 会很好。 usingreset --hard是用蒸汽锤打开鸡蛋
  • 您确实需要小心。例如,如果您签出了一个分支,reset --hard 将移动该分支并可能删除该分支指向的任何提交。 reset 真的是为了移动分支和该死的后果。如果你不小心,它会给你带来很多困难。 checkout 很多更安全
  • @Liam 是的,但在这种情况下,当前要修复的分支被暗示为要执行 reflogreset 的上下文。在git reset --soft 之后,我不明白git checkout HEAD(因为 HEAD 现在指向错误的提交)会有什么用......我错过了什么?
  • 应该是master(或其他)。我不经常使用命令行。我只是指出这可能非常危险。 reset should be used with extreme caution, it can easily result in lost code.
  • 我认为 RomainValeri 是对的。我试图检查 HEAD 但它没有做任何事情,因为当前的 HEAD 是我重置的提交。但我会牢记这一点,以备不时之需——不要轻易改变重置。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2020-06-25
  • 2014-02-28
  • 2013-09-29
  • 2022-11-05
  • 2018-02-21
  • 2011-12-06
  • 1970-01-01
相关资源
最近更新 更多