git reset --hard 求救哈

看看 IDE 里有没有记录吧

idea 文件历史记录

不出意外应该是救不了了，如果远端仓库没备份的话，只能试试数据恢复软件。

立刻断电，硬盘拆下来到另一台电脑做数据恢复

git reflog 应该能看到每次的操作 id ，可以回到那个 id 状态

@xcsoft 他是暂存区文件，肯定没了

如果你用 jetbrains 就没事了，这钱是不能省的

@golangLover 我用的 phpstorm ，请问有办法恢复吗？

右键项目，然后在 local history 里面看看有没有

@maninfog 牛逼啊 果然有，不过我记得 git reflog 是能恢复的吗？

git reflog 并不记录 add 命令

但暂存区也是会有 object 文件的，最后实在不行的笨办法也可以根据文件更新时间手动寻找并恢复

git reflog 我理解只会给你提供之前 HEAD 对应的 commit id ，适用于你提交了代码的情况，并且 git 会定期清除一些无用的 commit ，所以还有时限要求

感谢楼上各位，感谢 jetbrains ，感谢 phpstorm ，文件已经恢复了。

借此讨论下，已经 add 但是还没 commit 的 文件 当 reset --hard 后 真的没有办法通过 git 本身的手段找回吗？

git reflog 也不行吗？

reset hard 本来就是硬重置, git 本身肯定没法找回了...得借助另外的工具... 所以相应的, reset 还有 soft mix...

没 commit 的文件不属于 git 管辖范围，怎么通过 git 的手段来找回呢。
首先得让更改进 git 才行啊。

还没 commit 就还没提交给版本库，那肯定没有记录的。

local history 救过我好几命

暂存区确实没有 reflog ，但是会有 object 文件，我就找回来过，不过挺麻烦的

reflog 肯定没用，只在暂存区，还是重新实现一下吧。

用 jetbrains 的话，在需要恢复的文件内直接 Ctrl +Z 就能恢复

借楼问：如果是重要的变更，是不是要开一个新分支，频繁临时提交，最后再改提交信息，以避免这个问题？

用 idea 系列的 ide ，只要 local history 没被清除，那还有的救

本人亲测，只有 add 也可以找回，用这个脚本
https://github.com/ethomson/git-recover

@tlerbao #11 你是用 local history 回复的吗？ 做个备份

@HankAviator

”借楼问：如果是重要的变更，是不是要开一个新分支，频繁临时提交，最后再改提交信息，以避免这个问题？“

A：良好的 Git 使用习惯就是应该每完成一个小的功能点就 commit 的一下，以后找起来也方便，既然都已经觉得是重要的了，就更要谨慎操作每一步了。其实除了这种误操作执行 git 命令的，还有更要命的就是掉盘，会有概率因文件被占用导致填零

https://www.yuque.com/licsber/blog/pl88o4

果然。。大家总会在差不多的时间碰到差不多的问题

恭喜

没事整什么 stash ，又低效又难用。同样没备份，hg mq 不知高哪去了。
不用 stash ，老实多 commit ，直球 reset 也无所谓，反正能 reflog 。

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

@FrankHB hg mq 这么 NB ，怎么还没把 git 干掉

local history

@HankAviator 难道不应该是任何变更都是新开一个分支吗

后续怎样，在主分支上将此次修改的最终结果 git merge 进来？新开分支上的 commit 历史怎么办 or 丢弃新开分支本身吗
@littlewing

@tlerbao 如果需要回滚并且保留暂存文件，或许你需要的命令是 git reset <commit id>

只能说 Jetbrains 家的 IDE 是最好用的版本控制工具了（？

@littlewing 只是 op 丢未提交的内容这一部分，如果提交了就好找回了，重点是频繁临时提交

《论有一个完善的 IDE 的重要性》

真幸福，还有机会抢救。我上次脑子抽了直接把.git 给删了，删之前还把代码 stash 了一下，当时心态就崩溃了。。。。

还有个 lost&found 可以找，add 过的应该都可以找回来

这个目录不要操作任何先。
复制一份，查看里面的.git ，你能看到类似某个 hasd 的，一个个找出来。

没事多 commit ，用 interactively rebase 干啥都行

@hO0O0 哈哈哈怎么想的

从楼主的教训得出：没事操作 reset 干啥。

如果用的是 JB IDE,可以在 local history 里找到

git reflog show [branch-name]
试试能不能找到

@ElmerZhang hg mq 一点都不 nb ，只不过 hg CLI 的一些基础设计真没 git CLI 设计得那么傻缺，拿过来开箱即用而体现出日用体验优势了。
要干掉也是 hg 整个干掉 git ，不过 GitHub dssq 呗……（这种 SO/YC 之类的一搜一大把就不具体引用了。）要我说就是绝大多数日常用户甚至都还没到用出差别的水平（除了 hg 存小文件效率和 git 断点续传更欠扁的个别问题），用哪个基本就是随大流，git 更网红所以更常见罢了。
另外现在 mq 是 hg 官方都不建议用了（ www.mercurial-scm.org/wiki/MqExtension ）。毕竟 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 ）。

我也出过类似的问题，后来写了这个 https://github.com/xuzhongping/rusure

reset --hard 的意图就是丢弃当前工作回到以前的某个状态，所以在执行之前一定要确认还没提交 /stash 的内容，确实是要丢弃的，如果不是那就先 stash 或提交。

@tlerbao “已经 add 但是还没 commit 的 文件 当 reset --hard 后 真的没有办法通过 git 本身的手段找回吗？”

git 管不了这个

如果还记得改了哪些文件 本地历史还能救回一些

不要让代码在你的电脑上过夜, 哈哈, 没事就 commit