我創建了一個Git倉庫GitHub for Windows，並做了重置之前提交我的文件，現在我已經失去了我所有的項目/文件。git rebase blob重置後丟失了變化
我找到的文件與
$ git fsck --lost-found
我的文件是在.git\lost-found\other，我可以用$ git show SHA查看它們，但是當我做了$ git rebase SHA我得到這個：
error: Object SHA is a blob, not a commit
fatal: Needed a single revision
invalid upstream SHA
我能做些什麼恢復我的文件？
或者，可以用其他程序或語言讀取文件？
我不是太熟悉一般git的恢復，但你可能想看看這個計算器的問題：
Accidentally reverted to master, lost uncommitted changes
假設你沒有git add，git stash和git commit更改。所以我認爲上述問題的接受答案中概述的方法都不起作用。
根據你所說的，在執行git fsck --lost-found之後，你的文件現在位於.git\lost-found\other文件夾中，你可以使用git show <SHA1>查看blob。 git rebase只適用於提交而不是blob，這就是爲什麼它不起作用。
我認爲最安全的方法是編寫腳本或手動爲每個blob執行git show並將輸出傳輸到文件。假設有一個名爲4156fb7a的blob，它最初是存儲庫中的README.txt文件。你會做：
git show 4156fb7a > README.txt
，使得Blob的內容現在得到輸出README.txt。如果你手動完成這個過程將是單調乏味的，但這可能是一個安全的方法。
我認爲.git\lost-found\other文件夾中不存在的任何東西都可以被認爲會丟失。請記得提前和經常提交。希望有所幫助。
編輯更新答案：
@Malaka，如果沒有大量的斑點，你也可以自己檢查它們。否則，這只是一個猜測，但我猜你可能沒有修改所有900個文件。如果你記得你修改了什麼，那麼修復工作就容易多了。否則，你可能想看看我的建議如下。
我要建議的是可能或不可能解決的問題。它假定存在另一個原始文件的文件夾，無論該文件夾是否是git repo或其他文件夾。如果你沒有其他原始文件夾/回購，那麼我的下面的想法是無用的。
第1步：
編寫應用一些校驗一種計算機程序，說SHA1（使用sha1sum效用;如果不存在，使用md5sum）在原始文件夾中，在每一個文件。該計算機程序將最終產生具有以下格式的文本文件：
fullFileName<SP>SHA1 checksum
凡<SP>代表的空間。所以我們可以說我在原來的文件夾/回購下列文件：
app/controllers/ApplicationController.rb
assets/utilities.js
README.markdown
那麼你的程序將生成一個看起來像下面這樣的文件。校驗都是由課程：
app/controllers/ApplicationController.rb 01dfea13
assets/utilities.js 55a31aae
README.markdown 9671c6a0
我們會從現在開始參照上述文件爲checksumfile。
我希望您的原始文件不要使用空格。如果他們有，只需使用其他分隔符來分隔文件名及其校驗和。
第2步：
現在，另寫計算機程序（我們稱之爲blobCat）適用git show在.git\lost-found\other文件夾中的每一個斑點，並輸出到一些任意命名的文件在另一個文件夾。我們將通過unknownBlobs來表示該文件夾。爲了簡單起見，您可以輸出它們來說0.txt,1.txt,2.txt等等，換句話說，就是用一些整數計數器來命名它們。
完成後，編寫另一個程序，讀入checksumfile，並使用字典將校驗和索引爲原始文件名。換句話說，給定上述checksumfile，我們將產生下面的字典/散列：
"01dfea13" => "app/controllers/ApplicationController.rb" 01dfea13
"55a31aae" => "assets/utilities.js"
"9671c6a0" => "README.markdown"
現在，遍歷由blobCat程序產生的unknownBlobs文件夾（包含所有0.txt，1.txt，2.txt文件的文件夾），並在生成checksumfile時應用與第一步中相同的校驗和實用程序。如果您在字典中找到校驗和，這意味着該blob很可能是，並且您可以安全地將其還原到另一個文件夾中的層次結構。如果存在校驗和衝突，您可能需要檢查是否存在具有相同校驗和的另一個Blob，儘管這種情況不太可能發生。
對於已在詞典中查不到的校驗和unknownBlobs文件夾的任何斑點，這可能意味着以下任何一項：
在任何情況下，新創建的文件，只保留那些斑點的軌道在DI沒有發現ctionary，並在每件事物的最後輸出他們的名字。這應該是一個相當小的一組blob，因此您可以手動檢查它們並確定它們是否是您原始存儲庫的一部分，然後將它們複製到其目標位置（如果它們是）。
上面聽起來很乏味，但我認爲它比嘗試自己檢查所有斑點要快得多，假設有很多斑點。
可能重複[撤消git reset？]（http://stackoverflow.com/questions/2510276/undoing-git-reset） – Phil
不，我的文件沒有提交，所以我（想）沒有什麼HEAD和$ git reflog只返回我做的第一個提交。 – Metalaka
啊，那麼也許檢查這個答案 - http://stackoverflow.com/a/6780036/283366 – Phil