恢复 git reset --hard

运行：git fsck --lost-found

If you didn’t already commit your local changes (or at least stage them via git add, they’re gone. git reset --hard is a destructive operation for uncommitted changes.

If you did happen to stage them, but didn’t commit them, try git fsck --lost-found and then search through the contents of .git/lost-found - it will contain all of the objects that aren’t referenced by a known commit, and may include versions of files that were staged.
You can recover anything you git added, with git fsck --lost-found and poke around in .git/lost-found. find .git/objects -type f | xargs ls -lt | sed 60q will give you the last 60 things to get added to the repo, that’ll help.

Anything you didn’t git add is gone as surely as if you’d deleted it yourself.

查看.git\lost-found\other文件夹

添加暂存区有几个文件，还原后。执行git fsck --lost-found后目录下就会有几个文件，几个文件提交的内容不是合并在一起存储的，而是分开存储的（已实验）。
如果同一个文件多次修改存储在暂存区，存储几次就会有几个文件，文件内容是每次放在暂存区的文件完整的内容。如：第一次提交：内容1。文件追加内容2。第二次提交：内容1内容2。两个文件的内容分别是：内容1；内容1内容2；

从.git\lost-found\other目录下一个个查找自己所丢失的代码。

C:\Users\root\Desktop\code>git fsck --lost-found
Checking object directories: 100% (256/256), done.
Checking objects: 100% (766/766), done.
dangling blob 718814a3ca5fb40ed7afbbb56f72add25d558afd
dangling blob fc702dc9543487405c4be006b3262f25e0ce8241
dangling blob 29693351eec7e14f235551a2767aaa5a62e8d3ed
dangling blob 0e1adde785ce86b7f6743adf2d24fddf960826ec
dangling blob 38526e3454e03ef27bb726893d8c2c9ec138943f
dangling blob 93eaf863602f1a3da66ff6ac7652bec5c4a7560c
dangling blob b5aa303404f9eee4c488707ed41f2c8559872f08
dangling blob d232582d96deb90619a7d9e5eb0661b671ada087
dangling blob d4ca7d3d03ff6de6f386216493a08a18b3be5132
dangling blob 0d74b9bc9a842545d5efcdd7536d5de6f1e444d2
dangling blob 3cac599a02af6363e589a0df9869d6deb5e45fed
dangling blob b264839eed419acd77300556478a919a250be4b1
dangling blob d31cc60d3a449415630bc80069d60a1eac964f7a
dangling blob 24dde2c53156489b59db42387593e5db0d85c791
dangling blob aa454f940f68ff4be17846e1a77a164f1ae7541a
dangling blob b2a56a814d6a40403eaa76d8f589a17f95d35a42
dangling blob db95c741c4ff22af0c3681fece2bf41a6bd289d0
dangling blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
dangling blob aefef6e96da5b79e11499b37418916bc0e47ba41
dangling blob bc3e8f7f96d1f3db9c13a281d46fcc6c89b8a1dc
dangling blob dd869ac5a251695bcb147d74ab359fc540ed1e28
dangling blob 58ff9d3875d23c556b18e228fffcd8dbb47bd096

git gc和fsck的用法

一、保证git良好的性能
在大的仓库中, git靠压缩历史信息来节约磁盘和内存空间.
压缩操作并不是自动进行的, 你需要手动执行 git gc:
$ git gc
压缩操作比较耗时, 你运行git gc命令最好是在你没有其它工作的时候.
二、保持git的可靠性
git fsck 运行一些仓库的一致性检查, 如果有任何问题就会报告. 这项操作也有点耗时, 通常报的警告就是“悬空对象"(dangling objects).
$ git fsck
dangling commit 7281251ddd2a61e38657c827739c57015671a6b3
…
“悬空对象"(dangling objects)并不是问题, 最坏的情况只是它们多占了一些磁盘空间. 有时候它们是找回丢失的工作的最后一丝希望.

参考：

https://www.cnblogs.com/dylancao/p/6625431.html
https://blog.csdn.net/yeluosc/article/details/76690678
https://www.jianshu.com/p/4cd5983586b2