git reset --hard 求救哈

tlerbao 会员 2022年4月23日 08:44 发表

• 

  IceBay 会员

  2022年4月23日 08:44
  看看 IDE 里有没有记录吧
  0 0
  评论

• 

  v2kt 会员

  2022年4月23日 08:44
  idea 文件历史记录
  0 0
  评论

• 

  hxy100 会员

  2022年4月23日 08:44
  不出意外应该是救不了了，如果远端仓库没备份的话，只能试试数据恢复软件。
  0 0
  评论

• 

  villivateur 会员

  2022年4月23日 08:44
  立刻断电，硬盘拆下来到另一台电脑做数据恢复
  0 0
  评论

• 

  litujin1123 会员

  2022年4月23日 08:44
  git reflog 应该能看到每次的操作 id ，可以回到那个 id 状态
  0 0
  评论

• 

  xcsoft 会员

  2022年4月23日 08:44
  试试 reflog
  0 0
  评论

• 

  villivateur 会员

  2022年4月23日 08:44
  他是暂存区文件，肯定没了
  0 0
  评论

• 

  golangLover 会员

  2022年4月23日 08:44
  如果你用 jetbrains 就没事了，这钱是不能省的
  0 0
  评论

• 

  tlerbao 会员 (楼主)

  2022年4月23日 08:44
  我用的 phpstorm ，请问有办法恢复吗？
  0 0
  评论

• 

  maninfog 会员

  2022年4月23日 08:44
  右键项目，然后在 local history 里面看看有没有
  0 0
  评论

• 

  tlerbao 会员 (楼主)

  2022年4月23日 08:44
  牛逼啊 果然有，不过我记得 git reflog 是能恢复的吗？
  0 0
  评论

• 

  baiyi 会员

  2022年4月23日 08:44
  git reflog 并不记录 add 命令 但暂存区也是会有 object 文件的，最后实在不行的笨办法也可以根据文件更新时间手动寻找并恢复
  0 0
  评论

• 

  xcsoft 会员

  2022年4月23日 08:44
  自己试了下, 的确不行, 只能想其他办法了
  0 0
  评论

• 

  maninfog 会员

  2022年4月23日 08:44
  git reflog 我理解只会给你提供之前 HEAD 对应的 commit id ，适用于你提交了代码的情况，并且 git 会定期清除一些无用的 commit ，所以还有时限要求
  0 0
  评论

• 

  tlerbao 会员 (楼主)

  2022年4月23日 09:14
  感谢楼上各位，感谢 jetbrains ，感谢 phpstorm ，文件已经恢复了。 借此讨论下，已经 add 但是还没 commit 的 文件 当 reset --hard 后 真的没有办法通过 git 本身的手段找回吗？ git reflog 也不行吗？
  0 0
  评论

• 

  wu67 会员

  2022年4月23日 09:14
  reset hard 本来就是硬重置, git 本身肯定没法找回了...得借助另外的工具... 所以相应的, reset 还有 soft mix...
  0 0
  评论

• 

  msg7086 会员

  2022年4月23日 09:14
  没 commit 的文件不属于 git 管辖范围，怎么通过 git 的手段来找回呢。 首先得让更改进 git 才行啊。
  0 0
  评论

• 

  SenLief 会员

  2022年4月23日 09:14
  还没 commit 就还没提交给版本库，那肯定没有记录的。
  0 0
  评论

• 

  misdake 会员

  2022年4月23日 09:46
  local history 救过我好几命
  0 0
  评论

• 

  des 会员

  2022年4月23日 10:44
  暂存区确实没有 reflog ，但是会有 object 文件，我就找回来过，不过挺麻烦的
  0 0
  评论

• 

  461da73c 会员

  2022年4月23日 11:14
  reflog 肯定没用，只在暂存区，还是重新实现一下吧。
  0 0
  评论

• 

  eggt 会员

  2022年4月23日 11:14
  用 jetbrains 的话，在需要恢复的文件内直接 Ctrl +Z 就能恢复
  0 0
  评论

• 

  HankAviator 会员

  2022年4月23日 11:14
  借楼问：如果是重要的变更，是不是要开一个新分支，频繁临时提交，最后再改提交信息，以避免这个问题？
  0 0
  评论

• 

  oneisall8955 会员

  2022年4月23日 12:14
  用 idea 系列的 ide ，只要 local history 没被清除，那还有的救
  0 0
  评论

• 

  molvqingtai 会员

  2022年4月23日 12:46
  本人亲测，只有 add 也可以找回，用这个脚本
  0 0
  评论

• 

  christin 会员

  2022年4月23日 13:45
  #11 你是用 local history 回复的吗？ 做个备份
  0 0
  评论

• 

  Rache1 会员

  2022年4月23日 15:15
  ”借楼问：如果是重要的变更，是不是要开一个新分支，频繁临时提交，最后再改提交信息，以避免这个问题？“ A：良好的 Git 使用习惯就是应该每完成一个小的功能点就 commit 的一下，以后找起来也方便，既然都已经觉得是重要的了，就更要谨慎操作每一步了。其实除了这种误操作执行 git 命令的，还有更要命的就是掉盘，会有概率因文件被占用导致填零 😂
  0 0
  评论

• 

  Licsber

  2022年4月23日 15:46
  果然。。大家总会在差不多的时间碰到差不多的问题
  0 0
  评论

• 

  phithon 会员

  2022年4月23日 17:14
  恭喜
  0 0
  评论

• 

  FrankHB 会员

  2022年4月23日 20:14
  没事整什么 stash ，又低效又难用。同样没备份，hg mq 不知高哪去了。 不用 stash ，老实多 commit ，直球 reset 也无所谓，反正能 reflog 。
  0 0
  评论

• 

  FrankHB 会员

  2022年4月23日 20:14
  如果说的是 staging area ，这货就不配叫暂存区，特么根本就没存内容。 这个多此一举模拟 GUI 的 checkbox list 的二缺设计……算了不浪费口水了，还是多 commit 吧。。。 硬要模拟 index 也是被 hg mq 吊打，人还能不止一个……
  0 0
  评论

• 

  kestrelBright 会员

  2022年4月24日 03:14
  local history
  0 0
  评论

• 

  littlewing 会员

  2022年4月24日 03:44
  难道不应该是任何变更都是新开一个分支吗
  0 0
  评论

• 

  charlie21 会员

  2022年4月24日 03:44
  后续怎样，在主分支上将此次修改的最终结果 git merge 进来？新开分支上的 commit 历史怎么办 or 丢弃新开分支本身吗
  0 0
  评论

• 

  Junzhou 会员

  2022年4月24日 04:14
  如果需要回滚并且保留暂存文件，或许你需要的命令是 git reset <commit id>
  0 0
  评论

• 

  crayygy 会员

  2022年4月24日 04:44
  只能说 Jetbrains 家的 IDE 是最好用的版本控制工具了（？
  0 0
  评论

• 

  HankAviator 会员

  2022年4月24日 05:14
  只是 op 丢未提交的内容这一部分，如果提交了就好找回了，重点是频繁临时提交
  0 0
  评论

• 

  qiyuey 会员

  2022年4月24日 05:45
  《论有一个完善的 IDE 的重要性》
  0 0
  评论

• 

  hO0O0 会员

  2022年4月24日 06:44
  真幸福，还有机会抢救。我上次脑子抽了直接把.git 给删了，删之前还把代码 stash 了一下，当时心态就崩溃了。。。。
  0 0
  评论

• 

  thulof 会员

  2022年4月24日 06:44
  还有个 lost&found 可以找，add 过的应该都可以找回来
  0 0
  评论

• 

  shenqi 会员

  2022年4月24日 06:44
  这个目录不要操作任何先。 复制一份，查看里面的.git ，你能看到类似某个 hasd 的，一个个找出来。
  0 0
  评论

• 

  sola97 会员

  2022年4月24日 06:44
  没事多 commit ，用 interactively rebase 干啥都行
  0 0
  评论

• 

  yuzhouwww 会员

  2022年4月24日 08:14
  哈哈哈怎么想的
  0 0
  评论

• 

  Felldeadbird 会员

  2022年4月24日 08:45
  从楼主的教训得出：没事操作 reset 干啥。
  0 0
  评论

• 

  zhuweiyou 会员

  2022年4月24日 08:45
  如果用的是 JB IDE,可以在 local history 里找到
  0 0
  评论

• 

  ooee2016 会员

  2022年4月24日 08:45
  git reflog show [branch-name] 试试能不能找到
  0 0
  评论

• 

  FrankHB 会员

  2022年4月24日 08:45
  hg mq 一点都不 nb ，只不过 hg CLI 的一些基础设计真没 git CLI 设计得那么傻缺，拿过来开箱即用而体现出日用体验优势了。 要干掉也是 hg 整个干掉 git ，不过 GitHub dssq 呗……（这种 SO/YC 之类的一搜一大把就不具体引用了。）要我说就是绝大多数日常用户甚至都还没到用出差别的水平（除了 hg 存小文件效率和 git 断点续传更欠扁的个别问题），用哪个基本就是随大流，git 更网红所以更常见罢了。 另外现在 mq 是 hg 官方都不建议用了（ ）。毕竟 mq 不是为了体现竞品傻缺发明出来的，而是为了替代早年 hg 没有 rebase 。这又是因为 hg 早年排斥修改历史的传统。然后这里 hg 还是怂了，于是有了 strip 有了 histedit 有了 rebase ，所以修改历史这个最主要的目的就用不上 mq 了。mq 仍然有用，主要适合专业对付 patch series 的 maintainer ，而 git 核心用户一开始也强调对了这个需求，并且设计得并不傻缺——直接开 branch （ hg 对应 git branch 的 bookmark 也不是一开始有的），处理 patch queue 时跟 hg mq 的实际日常用法大同小异；种种因素使 git 中一直有（不严格）对应的功能，但具体用法反而没那么大存在感（间接增长了类似 OP 这里的问题）。 这里鼓励 git 多 commit 也不可能是一个 branch 上蹲点（这里也有不少人表示新开 branch 算是常识了），所以核心用法跟 mq 差不多（只不过不强调是 patch ）。
  0 0
  评论