我也遇到过类似的问题。我的笔记本电脑在Git操作期间没电了。嘘。

我没有备份。(注意:Ubuntu One不是Git的备份解决方案;它将有助于覆盖你的健全的存储库与你的损坏。)

对于Git向导，如果这是一种糟糕的修复方法，请留下评论。然而，它确实对我有用……至少暂时是这样。

第一步:备份。git文件夹(事实上我在每一步之间都会做一些改变，但是会有一个新的copy-to名称，例如。git-old-1， .git-old-2，等等):

cd ~/workspace/mcmc-chapter
cp -a .git .git-old

步骤2:执行git fsck——full命令

git fsck --full

error: object file .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e is empty
fatal: loose object 8b61d0135d3195966b443f6c73fb68466264c68e (stored in .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e) is corrupt

步骤3:删除空文件。我想管他呢;反正是空白的。

rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e

rm: remove write-protected regular empty file `.git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e'? y

步骤3:重新执行git fsck命令。继续删除空文件。您也可以cd到.git目录并运行find。-type f -empty -delete -print删除所有空文件。最终Git开始告诉我它实际上在对对象目录做一些事情:

git fsck --full

Checking object directories: 100% (256/256), done.
error: object file .git/objects/e0/cbccee33aea970f4887194047141f79a363636 is empty
fatal: loose object e0cbccee33aea970f4887194047141f79a363636 (stored in .git/objects/e0/cbccee33aea970f4887194047141f79a363636) is corrupt

步骤4:在删除所有空文件后，我最终得到了git fsck实际运行:

git fsck --full

Checking object directories: 100% (256/256), done.
error: HEAD: invalid sha1 pointer af9fc0c5939eee40f6be2ed66381d74ec2be895f
error: refs/heads/master does not point to a valid object!
error: refs/heads/master.u1conflict does not point to a valid object!
error: 0e31469d372551bb2f51a186fa32795e39f94d5c: invalid sha1 pointer in cache-tree
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
missing blob 8b61d0135d3195966b443f6c73fb68466264c68e
missing blob e89896b1282fbae6cf046bf21b62dd275aaa32f4
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a
missing blob caab8e3d18f2b8c8947f79af7885cdeeeae192fd
missing blob e4cf65ddf80338d50ecd4abcf1caf1de3127c229

步骤5:尝试git reflog。失败是因为我的头坏了。

git reflog

fatal: bad object HEAD

步骤6:谷歌。发现这些。手动获取reflog的最后两行:

tail -n 2 .git/logs/refs/heads/master

f2d4c4868ec7719317a8fce9dc18c4f2e00ede04 9f0abf890b113a287e10d56b66dbab66adc1662d Nathan VanHoudnos <nathanvan@gmail.com> 1347306977 -0400    commit: up to p. 24, including correcting spelling of my name
9f0abf890b113a287e10d56b66dbab66adc1662d af9fc0c5939eee40f6be2ed66381d74ec2be895f Nathan VanHoudnos <nathanvan@gmail.com> 1347358589 -0400    commit: fixed up to page 28

步骤7:注意，从步骤6中我们了解到HEAD当前指向最后一次提交。让我们看一下父commit

git show 9f0abf890b113a287e10d56b66dbab66adc1662d

commit 9f0abf890b113a287e10d56b66dbab66adc1662d
Author: Nathan VanHoudnos <nathanvan@XXXXXX>
Date:   Mon Sep 10 15:56:17 2012 -0400

    up to p. 24, including correcting spelling of my name

diff --git a/tex/MCMC-in-IRT.tex b/tex/MCMC-in-IRT.tex
index 86e67a1..b860686 100644
--- a/tex/MCMC-in-IRT.tex
+++ b/tex/MCMC-in-IRT.tex

它工作!

第8步:现在我们需要将HEAD指向9f0abf890b113a287e10d56b66dbab66adc1662d。

git update-ref HEAD 9f0abf890b113a287e10d56b66dbab66adc1662d

它没有抱怨。

步骤9:看看fsck说了什么:

git fsck --full

Checking object directories: 100% (256/256), done.
error: refs/heads/master.u1conflict does not point to a valid object!
error: 0e31469d372551bb2f51a186fa32795e39f94d5c: invalid sha1 pointer in cache-tree
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
missing blob 8b61d0135d3195966b443f6c73fb68466264c68e
missing blob e89896b1282fbae6cf046bf21b62dd275aaa32f4
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a
missing blob caab8e3d18f2b8c8947f79af7885cdeeeae192fd
missing blob e4cf65ddf80338d50ecd4abcf1caf1de3127c229

第10步:缓存树中无效的sha1指针看起来像是来自一个(现在过时了)索引文件(源文件)。所以我杀了它，重置了存储库。

rm .git/index
git reset

Unstaged changes after reset:
M    tex/MCMC-in-IRT.tex
M    tex/recipe-example/build-example-plots.R
M    tex/recipe-example/build-failure-plots.R

步骤11:再次查看fsck…

git fsck --full

Checking object directories: 100% (256/256), done.
error: refs/heads/master.u1conflict does not point to a valid object!
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a

悬垂的斑点不是错误。我不关心主人。u1conflict，现在它工作了，我不想再碰它了!

第12步:跟进我的本地编辑:

git status

# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#    modified:   tex/MCMC-in-IRT.tex
#    modified:   tex/recipe-example/build-example-plots.R
#    modified:   tex/recipe-example/build-failure-plots.R
#
< ... snip ... >
no changes added to commit (use "git add" and/or "git commit -a")


git commit -a -m "recovering from the git fiasco"

[master 7922876] recovering from the git fiasco
 3 files changed, 12 insertions(+), 94 deletions(-)

git add tex/sept2012_code/example-code-testing.R
git commit -a -m "adding in the example code"

[master 385c023] adding in the example code
 1 file changed, 331 insertions(+)
 create mode 100644 tex/sept2012_code/example-code-testing.R

这种情况也经常发生在我身上。我没有制定具体何时发生这种情况的协议，但我怀疑每当我的虚拟机(VM)“意外”存在时就会发生这种情况。如果我关闭虚拟机窗口(我使用的是Ubuntu 18.04 (Bionic Beaver))并重新开始，事情总是(?)工作。但是如果当我的笔记本电脑关闭(Windows主机系统)时，虚拟机窗口仍然打开，那么我经常遇到这个问题。

对于这里给出的所有答案:

thank you - they are very useful; I usually save a local copy of my code, restore the repository from remote, and move the backup copy back into the local folder. as the underlying problem is not really a Git issue, but rather a VM and/or Linux issue, I wonder if there shouldn't be a way to cure the reason rather the symptoms? Doesn't this kind of error indicate that some file system changes are not "applied" in any reasonable time, but only cached? (see for example Are file edits in Linux directly saved into disk?) -- to me it appears as if virtual Linux machines don't fsynch their stuff frequently enough. Whether this is an issue of Oracle's VirtualBox (which otherwise works very nicely) or of the guest file system, or of some settings, which we all overlook, is beyond my expertise. But I would be happy if someone could shed light on this.

我从一个干净的分支机构退房后也遇到了同样的问题。

过了一段时间，我在master中发现了很多修改过的文件。我不知道为什么他们一直在那里，从一个干净的分支切换。不管怎样，因为修改后的文件对我来说没有意义，我只是把它们藏起来，错误就消失了。

git：（master） git stash

在我的例子中，出现这个错误是因为我正在输入提交消息，而我的笔记本关机了。

我执行了以下步骤来修复错误:

git checkout -b backup-branch # Create a backup branch git reset --hard HEAD~4 # Reset to the commit where everything works well. In my case, I had to back four commits in the head, that is until my head be at the point before I was typing the commit message. Before doing this step, copy the hash of the commits you will reset. In my case I copied the hash of the four last commits. git cherry-pick <commit-hash> # Cherry pick the reset commits (in my case are four commits, so I did this step four times) from the old branch to the new branch. git push origin backup-branch # Push the new branch to be sure everything works well git branch -D your-branch # Delete the branch locally ('your-branch' is the branch with problem) git push origin :your-branch # Delete the branch from remote git branch -m backup-branch your-branch # Rename the backup branch to have the name of the branch that had the problem git push origin your-branch # Push the new branch git push origin :backup-branch # Delete the backup branch from remote

我遇到了同样的问题，我用了一个非常简单的方法来解决它。我发现那些丢失的文件存在于我队友的电脑上。

我将这些文件一个一个地复制到Git服务器(总共9个文件)，这样就解决了这个问题。

因为我必须定期重启我的虚拟机，不知何故这个问题经常发生在我身上。几次之后，我意识到我不能每次都重复Nathan Vanhoudnos所描述的过程，尽管它总是有效的。然后我想出了以下更快的解决方案。

步骤1

将整个存储库移动到另一个文件夹。

mv current_repository temp_repository

步骤2

再次从原点克隆存储库。

git clone source_to_current_repository.git

步骤3

删除新存储库下的所有内容，除了.git文件夹。

步骤4

将temp_repository中的所有内容移到新的存储库中，除了.git文件夹。

步骤5

删除temp_repository，就完成了。

几次之后，我相信你可以很快地完成这些步骤。