由於操作不當，導致git版本庫出了大問題，如下所示：
error: object file .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e is empty fatal: loose object 8b61d0135d3195966b443f6c73fb68466264c68e (stored in .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e) is corrupt
即提示xx文件是空的。在使用git log、git commit、git status等命令都會出此錯誤（文件名可能不一樣）。如果把.git刪掉，重新init，那會很輕松地暴力地解決了這個問題。但是，這樣的話之前的版本信息就全部丟失了，這並不是想要的結果。於是，我打算修復它。
首先，貼上找到的正確解決方法的鏈接：http://stackoverflow.com/questions/11706215/how-to-fix-git-error-object-file-is-empty
如果看不懂，最後有簡單的版本
然後是說說我自己瞎搗鼓的過程：
當時我想，既然它提示那個文件是有問題的，那我把它刪了會怎麼樣呢？結果是提示另一個文件是空白的。也就是說，還得刪。我空發奇想，如果我修改了它的日志會怎麼樣？於是，我查看的它的日志文件：
cd .git cd logs vim HEAD
我發現日志文件前面都是我之前提交的版本信息，唯獨最後一行是亂碼。於是，我把亂碼行刪了。同時，cd 進另當前目錄下的一個子目錄中
cd refs cd heads vim master
把這裡最後一行的亂碼也刪了。
然後，我發現.git另一個子目錄refs裡，存著好像是當前版本信息的東西，參考之前的HEAD文件，把它改成了一個正常的版本號。此時，我使用git log，居然可以正常地顯示出日志了！然後我嘗試add了一下，發現OK，沒有提示任何東西。據說，沒有提示就是好事。可是，萬萬沒想到的是，在commit的時候，又開始提示xx文件是空的了。
看來，我是哪裡搞錯了什麼。
雖然自己瞎搗鼓沒有成功，但是似乎對git版本庫的文件結構稍微了解了一些：
[ccx@ubuntu ~/miniSearchEngin]$>cd .git/ [ccx@ubuntu ~/miniSearchEngin/.git]$>l branches/ COMMIT_EDITMSG config description HEAD hooks/ index info/ logs/ objects/ refs/
一個一個來看，首先，branches是一個空文件（我的是），“樹枝”的意思，大概是與分支有關的文件，我暫時沒用到分支，並不是很清楚。
COMMIT_EDITMSG，看文件名大概猜到是commit時的編輯信息，結果和猜測的一樣：
[ccx@ubuntu ~/miniSearchEngin/.git]$>cat COMMIT_EDITMSG 詞典聯想功能OK，目測可以多線程服務
與日志文件最後一行呼應：
31 e5085f07d6f8578bad1ae39d85bf88db6886c51d bd9a33f13603ef3b53184e3b9ce9408638b71fb4 ccx19930930 <[email protected]>
1480909458 +0800 commit: 詞典聯想功能OK，目測可以多線程服務
然後是description文件，好吧我不知道它是干嘛用的（下面省略掉不知道的吧，哪天搞明白了再補）
HEAD，裡面是一個文件路徑：
[ccx@ubuntu ~/miniSearchEngin/.git]$>cat HEAD ref: refs/heads/master
[ccx@ubuntu ~/miniSearchEngin/.git]$>cat refs/heads/master bd9a33f13603ef3b53184e3b9ce9408638b71fb4
文件內容與日志文件最後一項的後一個大數字相同。於是我猜測它可能是當前版本信息。
如果把HEAD刪了，或者裡面的路徑改了，會怎麼樣呢：
刪除的情況：
[ccx@ubuntu ~/miniSearchEngin/.git]$>mv HEAD HEAD.h [ccx@ubuntu ~/miniSearchEngin/.git]$>cd .. [ccx@ubuntu ~/miniSearchEngin]$>git log fatal: Not a git repository (or any of the parent directories): .git
改了的情況：
[ccx@ubuntu ~/miniSearchEngin]$>git log fatal: Not a git repository (or any of the parent directories): .git
就提示沒有git版本庫了。
如果手動把refs/heads/master改成之前的一個版本號，在git log的時候會顯示為之前的日志信息。就像是日志回檔了，但是文件還是原樣。反正我做了這個操作之後使用git status，會提示一堆紅色未提交的文件。進行add 和commit也是可以。此時查看日志文件，會發現最後一行新增了新信息。不妨把此操作命名為操作A。
這裡要說一下日志文件，截取部分如下：
1 0000000000000000000000000000000000000000 541115f2d1f08d2fe58a768e5a9d3a809bab1131 ccx19930930 <[email protected]> 1480061835 +0800 commit (initial): build git 2 541115f2d1f08d2fe58a768e5a9d3a809bab1131 31db0463027e42718de8e2bbd826586a89316723 ccx19930930 <[email protected]> 1480082783 +0800 commit: 中文、英文單詞詞頻統計，不包含全、半角標點符號 3 31db0463027e42718de8e2bbd826586a89316723 1a5c8107af4852b0d8d36a76d988cb2a0b06cc10 ccx19930930 <[email protected]> 1480128209 +0800 commit: 去停用詞 4 1a5c8107af4852b0d8d36a76d988cb2a0b06cc10 959fa05c58dbcb6837d7b7a9062bf2f542a15a6b ccx19930930 <[email protected]> 1480176053 +0800 commit: 分組OK
前兩個數字就好像是表示從哪個數字開始，到哪個數字，然後下一行的起始就是上一行的結束。由於refs/heads/master中存著當前版本號，於是我很happy地把它看成一個鏈表，以當前版本為頭結點的鏈表：
+=======+ +=======+ +========+ +=========+
|當前版本|-->|上一版本|-->...-->|第二個版本|-->|第一個版本|
+=======+ +=======+ +========+ +=========+
做了操作A之後：
+=======+ +=============+ +===============+ +========+
|當前版本|--+ |操作A之前的版本|-->...+->|操作A中設定的版本|-->...-->|第一個版本|
+=======+ | +=============+ | +===============+ +========+
| |
+-------------------------------+
就成這樣了。
objects文件夾裡存的應該是不同版本的文件，可能是經過了加密算法還是什麼算法，打開看基本是亂七八糟的不知道寫的什麼。
logs文件夾之前提到了，存的是日志文件。
refs文件夾存的是當前版本信息，“鏈表的頭結點”。
好了，裝逼（賣弄）了這麼久，回歸正題。
我最後是用一開始的鏈接裡的方法解決了解個問題：
在最最開始，要先備份一下.git文件夾，萬一搞壞了呢
首先，刪除所有的空白文件：
cd .git find . -type f -empty -delete -print
然後，打印出日志文件最後兩行：
tail -n 2 .git/logs/refs/heads/master
接著，查看xx版本是否正常，即上一步打印出來的第一條
git show xxxx(版本號)
之後，回檔：
git update-ref HEAD xxxx(版本號)
檢查一下：
git fsck
我到這一步就已經OK能用了，鏈接後面還有一些處理我並沒有繼續做下去（我比較懶，目的就只是修復一下版本庫，既然能用了我就不繼續搞了，萬一又壞了呢）
鏈接中剩余的操作：
rm .git/index git reset git fsck
然而，在寫此文的時候我發現，那位大神這樣做了之後並沒有什麼用，他也說了他並不想繼續搞了（英語渣，大概應該可能也許是這個意思），將就用吧--!
最後看了一下修復後的日志信息，發現就是相當於做了“鏈表刪除節點”的操作，那個錯誤的日志信息還是亂碼。我也不想去刪了，就怕又刪出迷之問題。
後記：
寫此文時，已距離我修復好git版本庫一周有余，備份的錯誤庫早已刪除（永久刪除，前幾天剛清了一次回收站--!），有些地方可能描述得不太清楚，忘見諒。
http://xxxxxx/Linuxjc/1178066.html TechArticle