由于操作不当，导致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://*.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，目测可以多线程服务
与日志文件最后一行呼应：
e5085f07d6f8578bad1ae39d85bf88db6886c51d bd9a33f13603ef3b53184e3b9ce9408638b71fb4 ccx19930930 <@qq.com>
+ 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。
这里要说一下日志文件，截取部分如下：
541115f2d1f08d2fe58a768e5a9d3a809bab1131 ccx19930930 <@qq.com> + commit (initial): build git
541115f2d1f08d2fe58a768e5a9d3a809bab1131 31db0463027e42718de8e2bbd826586a89316723 ccx19930930 <@qq.com> + commit: 中文、英文单词词频统计，不包含全、半角标点符号
31db0463027e42718de8e2bbd826586a89316723 1a5c8107af4852b0d8d36a76d988cb2a0b06cc10 ccx19930930 <@qq.com> + commit: 去停用词
1a5c8107af4852b0d8d36a76d988cb2a0b06cc10 959fa05c58dbcb6837d7b7a9062bf2f542a15a6b ccx19930930 <@qq.com> + commit: 分组OK
前两个数字就好像是表示从哪个数字开始，到哪个数字，然后下一行的起始就是上一行的结束。由于refs/heads/master中存着当前版本号，于是我很happy地把它看成一个链表，以当前版本为头结点的链表：
+=======+ +=======+ +========+ +=========+
|当前版本|-->|上一版本|-->...-->|第二个版本|-->|第一个版本|
+=======+ +=======+ +========+ +=========+
做了操作A之后：
+=======+ +=============+ +===============+ +========+
|当前版本|--+ |操作A之前的版本|-->...+->|操作A中设定的版本|-->...-->|第一个版本|
+=======+ | +=============+ | +===============+ +========+
| |
+-------------------------------+
就成这样了。
objects文件夹里存的应该是不同版本的文件，可能是经过了加密算法还是什么算法，打开看基本是乱七八糟的不知道写的什么。
logs文件夹之前提到了，存的是日志文件。
refs文件夹存的是当前版本信息，“链表的头结点”。
好了，装逼（卖弄）了这么久，回归正题。
我最后是用一开始的链接里的方法解决了解个问题：
在最最开始，要先备份一下.git文件夹，万一搞坏了呢
首先，删除所有的空白文件：
cd .git
find . -type f -empty -delete -print
然后，打印出日志文件最后两行：
tail -n .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版本库一周有余，备份的错误库早已删除（永久删除，前几天刚清了一次回收站--!），有些地方可能描述得不太清楚，忘见谅。