看起来您有一个损坏的树对象。您需要从其他人那里获取该对象。希望他们会有一个未损坏的版本。

如果您无法从其他人那里找到有效的版本，您可以通过猜测应该在那里的文件来重新构建它。您可能想要查看对象的日期和时间是否与它匹配。这些可能是相关的斑点。您可以从这些对象推断出树对象的结构。

看看Scott Chacon关于Git内部的截图。这将向您展示git在引子下是如何工作的，以及如果您真的卡住了，并且无法从其他人那里获得该对象，如何进行此侦探工作。

Try

git stash

这对我很管用。它会隐藏你没有提交的任何东西，从而解决了问题。

在我的(Windows)机器决定重新启动后，我得到了这个错误。

谢天谢地，我的远程存储库是最新的，所以我只是做了一个新的Git克隆…

我也有同样的问题(不知道为什么)。

此修复需要访问未损坏的存储库远程副本，并将保持本地工作副本的完整性。

但它也有一些缺点:

您将丢失任何未推送的提交记录，并且必须重新提交它们。 你会丢失所有的钱。

修复

从repo上面的父目录执行这些命令(将'foo'替换为项目文件夹的名称):

创建损坏目录的备份: cp -R foo foo-backup 创建远程存储库的新克隆到一个新目录: Git克隆Git @www.mydomain.de:foo foo-newclone 删除损坏的.git子目录: Rm -rf foo/.git 将新克隆的.git子目录移到foo中: mv foo-newclone /。git foo 删除临时新克隆的其余部分: Rm -rf foo-newclone

在Windows上，你需要使用:

copy而不是cp -R rmdir /S代替rm -rf 移动而不是mv

现在foo恢复了它原来的.git子目录，但所有的本地更改仍然在那里。Git状态、提交、拉取、推送等再次正常工作。

我也有同样的问题在我的裸远程git回购。经过大量的故障排除后，我发现我的一个同事提交了。git/objects中的一些文件的权限是440 (r—r-----)，而不是444 (r—r—r—)。在让同事用“chmod 444 -R objects”在裸git repo中更改权限后，问题得到了解决。

最好的办法可能是简单地从远程存储库(即GitHub或其他)重新克隆。不幸的是，你将失去任何未推送的提交和隐藏的更改，但你的工作副本应该保持完整。

首先对本地文件进行备份。然后从你的工作树的根开始:

rm -fr .git
git init
git remote add origin [your-git-remote-url]
git fetch
git reset --mixed origin/master
git branch --set-upstream-to=origin/master master

然后根据需要提交任何更改过的文件。

运行git stash;Git stash pop解决了我的问题

我遵循了这里的许多其他步骤;Linus对如何查看git树/对象并找到缺失内容的描述尤其有用。git恢复损坏的blob

但最后，对我来说，由于部分磁盘故障，我有松散/损坏的树对象，并且树对象不容易恢复/不被那个文档覆盖。

最后，我将冲突的对象/<ha>/<hash>移出，并使用git unpack-objects与最新克隆的包文件一起使用。它能够恢复丢失的树对象。

仍然给我留下了许多悬空的斑点，这可能是解压缩以前存档的东西的副作用，并在这里的其他问题中解决

user1055643的答案缺少最后一步:

rm -fr .git
git init
git remote add origin your-git-remote-url
git fetch
git reset --hard origin/master
git branch --set-upstream-to=origin/master master

我刚刚经历了这种情况——我的机器在写到Git回购时崩溃了，它被损坏了。我是这样修正的。

我首先查看有多少提交没有推送到远程回购，如下所示:

gitk &

如果你不使用这个工具，它是非常方便的——据我所知，在所有操作系统上都可用。这表明我的远程缺少两次提交。因此，我单击了指示最新远程提交的标签(通常是/remotes/origin/master)来获得哈希值(哈希值有40个字符长，但为了简洁起见，我在这里使用10个字符——这通常是可行的)。

下面就是:

14c0fcc9b3

然后我点击下面的提交(即远程没有的第一个)，并获得哈希值:

04d44c3298

然后我使用这两个来为这次提交做一个补丁:

git diff 14c0fcc9b3 04d44c3298 > 1.patch

然后我对另一个缺失的提交也做了同样的处理，即我使用了之前提交的哈希值和提交本身的哈希值:

git diff 04d44c3298 fc1d4b0df7 > 2.patch

然后我移动到一个新的目录，从远程复制回购:

git clone git@github.com:username/repo.git

然后我将补丁文件移动到新文件夹中，应用它们并提交它们与它们确切的提交消息(这些可以从git日志或gitk窗口中粘贴):

patch -p1 < 1.patch
git commit

patch -p1 < 2.patch
git commit

这为我恢复了东西(注意，对于大量的提交，可能有更快的方法来做到这一点)。然而，我很想看看损坏的回购树是否可以修复，答案是可以。使用如上所述的修复的repo，在损坏的文件夹中运行这个命令:

git fsck 

你会得到这样的结果:

error: object file .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d is empty
error: unable to find ca539ed815fefdbbbfae6e8d0c0b3dbbe093390d
error: sha1 mismatch ca539ed815fefdbbbfae6e8d0c0b3dbbe093390d

要进行修复，我将在损坏的文件夹中这样做:

rm .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d
cp ../good-repo/.git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d

即删除损坏的文件，并用一个好的文件替换它。你可能要做几次。最后，你可以运行fsck而不会出现错误。你可能会在报告中出现“悬空提交”和“悬空blob”行，这是你在这个文件夹中重新创建和修改的结果，这是OK的。垃圾收集器将在适当的时候清除它们。

因此(至少在我的情况下)损坏的树并不意味着丢失未推送的提交。

我在写提交信息的时候电脑死机了。重新启动后，工作树就像我离开时一样，我能够成功提交我的更改。

然而，当我试图运行git状态时，我得到了

error: object file .git/objects/xx/12345 is empty
fatal: loose object xx12345 (stored in .git/objects/xx/12345 is corrupt

与大多数其他答案不同，我并没有试图恢复任何数据。我只是需要Git停止抱怨空对象文件。

概述

“目标文件”是Git对您所关心的实际文件的散列表示。Git认为它应该有一个/文件的散列版本。无论存储在.git/object/xx/12345中的是什么，修复这个错误基本上就是找出“松散对象”应该表示哪个文件的问题。

细节

可能的选择似乎是

删除空文件 将文件转换为Git可以接受的状态

方法1:删除目标文件

我尝试的第一件事就是移动object文件

mv .git/objects/xx/12345 ..

但这并没有起作用——Git开始抱怨断开的链接。关于方法二。

方法2:修复文件

Linus Torvalds写了一篇关于如何恢复目标文件的文章，为我解决了这个问题。这里总结了关键步骤。

$> # Find out which file the blob object refers to
$> git fsck
broken link from    tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
           to    blob xx12345
missing blob xx12345

$> git ls-tree 2d926
...
10064 blob xx12345    your_file.whatever

这告诉你空对象应该是哪个文件的哈希值。现在你可以修理了。

$> git hash-object -w path/to/your_file.whatever

在这样做之后，我检查了. Git /objects/xx/12345，它不再是空的，Git停止抱怨。

这里有个箱子。碰巧的是，问题是损坏文件的所有权是root而不是我们的正常用户。这是由于在有人执行了“sudo su——”之后在服务器上进行的提交造成的。

首先，用以下方法识别损坏的文件:

$> git fsck --full

你应该会收到这样的回答:

fatal: loose object 11b25a9d10b4144711bf616590e171a76a35c1f9 (stored in .git/objects/11/b25a9d10b4144711bf616590e171a76a35c1f9) is corrupt

进入损坏文件所在的文件夹，并执行以下操作:

$> ls -la

检查损坏文件的所有权。如果这是不同的，只要回到你的回购的根，并执行:

$> sudo chown -R YOURCORRECTUSER:www-data .git/

希望能有所帮助!

我也得到了一个损坏的松散对象错误。

./objects/x/x

我通过进入损坏对象的目录成功地修复了它。我看到分配给该对象的用户不是我的git用户。我不知道它是怎么发生的，但我在那个文件上运行了chown git:git，然后它又工作了。

这可能是解决某些民族问题的潜在办法，但不是解决所有问题的必要办法。

垃圾收集解决了我的问题:

git gc --aggressive --prune=now

它需要一段时间才能完成，但是每个松散的对象和/或损坏的索引都是固定的。

我刚遇到过这样的问题。我的特殊问题是由系统崩溃引起的，它破坏了最近的提交(因此也破坏了主分支)。我没有强迫自己，想要重新做出承诺。在我的特殊情况下，我可以这样处理:

Make a backup of .git/: rsync -a .git/ git-bak/ Check .git/logs/HEAD, and find the last line with a valid commit ID. For me, this was the second most recent commit. This was good, because I still had the working directory versions of the file, and so the every version I wanted. Make a branch at that commit: git branch temp <commit-id> re-do the broken commit with the files in the working directory. git reset master temp to move the master branch to the new commit you made in step 2. git checkout master and check that it looks right with git log. git branch -d temp. git fsck --full, and it should now be safe to delete any corrupted objects that fsck finds. If it all looks good, try pushing. If that works,

这对我很管用。我怀疑这是一个相当常见的场景，因为最近的提交是最有可能被损坏的，但如果你丢失了一个更早的提交，你可能仍然可以使用这样的方法，小心地使用git cherrypick，并在.git/logs/HEAD中reflog。

只需删除。git文件夹并重新添加。这个简单的解决方法对我很有效。

对我来说，这是由于在做git推时发生的电源故障。

这些信息是这样的:

$ git status
error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty
error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty
fatal: loose object c238824eb3fb602edc2c49fccb535f9e53951c74 (stored in .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74) is corrupt

我尝试了git fsck之类的东西，但这没有帮助。 由于崩溃发生在git推送期间，它显然发生在客户端重写期间，发生在服务器更新之后。我环顾四周，发现c2388在我的例子中是一个提交对象，因为它是由.git/refs中的条目引用的。所以我知道，当我查看历史(通过web界面或第二个克隆)时，我将能够找到c2388。

在第二个克隆中，我执行了git log -n 2 c2388来识别c2388的前身。然后我手动修改了.git/refs/heads/master和.git/refs/remotes/origin/master作为c2388的前身，而不是c2388。 然后我可以进行git取回。 git获取失败了几次，因为空对象上的冲突。我删除了这些空对象，直到git获取成功。这已经修复了存储库。

在虚拟机上工作，在我的笔记本上，电池没电了，得到这个错误;

error: object file .git/objects/ce/theRef为空 文件.git/objects/ce/theRef是空的 (存储在.git/objects/ce/theRef中)已损坏

我设法让回购工作再次只有2个命令，而没有丢失我的工作(修改文件/未提交的更改)

find .git/objects/ -size 0 -exec rm -f {} \;
git fetch origin

在那之后，我运行了git状态，回购很好，有我的更改(等待提交，现在就做…)

Git版本1.9.1

请记住备份您所记得的所有更改，以防此解决方案不起作用，需要更激进的方法。

我是这样解决的: 我决定简单地将未损坏的对象文件从备份的克隆复制到原始存储库。这个方法同样有效。(顺便说一下:如果你在.git/objects/中找不到它的名字，它可能已经被[打包][包]以节省空间。)

当我遇到这个问题时，我备份了我最近的更改(因为我知道我已经更改了什么)，然后删除了它在.git/location中抱怨的文件。然后我做了一个“少不再来”的动作。不过要小心，这可能不适合你。

简单地运行一个git修剪修复了这个问题

当我的系统崩溃时，我遇到了这种情况。我所做的是:

(请注意，您的损坏提交将丢失，但更改将保留。你可能必须在这个过程结束时重新创建这些提交)

备份代码。 转到您的工作目录并删除.git文件夹。 现在将远程复制到另一个位置，并在其中复制.git文件夹。 将其粘贴到工作目录中。 做你想做的事。

创建备份并将存储库克隆到一个新目录

cp -R foo foo-backup
git clone git@url:foo foo-new

(可选)如果你在不同的分支上工作，切换它。

cd foo-new
git checkout -b branch-name origin/branch-name

同步除.git目录外的更改

rsync -aP --exclude=.git foo-backup/ foo-new

当在同一个git签出中使用不同版本的不同git客户端时，通常会出现此问题。认为:

命令行 IDE内置git docker / vm容器内部 GIT gui工具

确保您使用创建提交的同一客户端进行推送。

我没有失去其他未被推的树枝: 对破碎对象的引用应该在refs/heads/<current_branch>中。如果你转到。git\logs\refs\heads\<current_branch>，你可以看到上次提交的值完全相同。我将之前提交的文件复制到第一个文件中，它解决了这个问题。

Felipe Pereira(上图)提供的解决方案，加上Stephan对我在对象被损坏时所在分支名称的回答的评论，对我来说是有效的。

find .git/objects/ -size 0 -exec rm -f {} \;
git fetch origin
git symbolic-ref HEAD refs/heads/${BRANCH_NAME}

您不需要克隆，也不需要丢失未提交的更改。只需使用git rm -rf .git/删除。git文件夹，然后通过启动一个新的repo，设置remote和重置head来恢复git文件夹。我在这里添加了恢复已删除git文件夹的说明:

https://stackoverflow.com/a/67610397/7584643

这似乎是Dropbox或符号链接文件夹出Dropbox为我的一个问题。其他类似的服务可能也是如此。当我去git push时，我会得到腐败松散对象错误。对我来说，在macOS Big Sur上，修复方法只是将回购的递归副本复制到Dropbox之外的目录中。我相信这导致Dropbox为损坏的动态引用拉出实时文件。复制后，我立即能够git推送没有错误。

我在一台Windows 10电脑上遇到了类似的问题，其中一个驱动器备份了我的文档文件夹，其中有我的git存储库。

查看git对象目录中的对象，我没有看到绿色的复选标记，而是该文件的蓝色同步图标。所有其他目标文件似乎都有绿色的复选标记。玩周围，尝试的东西，我尝试选择选项始终保持此文件夹在此设备上，但得到一个错误:错误0x80071129标签存在于重解析点缓冲区是无效的。

这个链接(https://answers.microsoft.com/en-us/msoffice/forum/all/error-0x80071129-the-tag-present-in-the-reparse/b8011cee-98c5-4c33-ba99-d0eec7c535a0)建议以管理员身份运行chkdsk /r /f来解决这个问题(必须重新启动计算机)。我这么做了，问题就解决了。

我以前也遇到过同样的问题。 我只是通过从.git/objects目录中删除object文件来传递它。

对于下面的错误。

$ git fsck
error: inflate: data stream error (invalid distance too far back)
error: corrupt loose object '45ba4ceb93bc812ef20a6630bb27e9e0b33a012a'
fatal: loose object 45ba4ceb93bc812ef20a6630bb27e9e0b33a012a (stored in .git/objects/45/ba4ceb93bc812ef20a6630bb27e9e0b33a012a) is corrupted

解决方案:

转到顶部目录并取消隐藏.git文件夹

在windows上，你可以在cmd上运行这个命令:attrib +s +h .git

然后进入。git/objects文件夹 如上所述的错误消息(存储在.git/objects/45/ba4ceb93bc812ef20a6630bb27e9e0b33a012a)已损坏 您可以看到该对象位于名为“45”的指示器上。因此，进入“。git/objects/45/”目录 最后找到名为ba4ceb93bc812ef20a6630bb27e9e0b33a012a的对象并删除它。

现在，您可以继续使用git status或git add进行检查。您的更改并继续。

有同样的问题后，我的linux薄荷崩溃，我按下电源按钮关闭我的笔记本电脑，这就是为什么我的。git是腐败的

find .git/objects/ -empty -delete

在那之后，我得到致命错误:坏对象头。我刚刚重新初始化了我的git

git init

并从远程repo获取

git fetch

要检查git，请使用

git status

又是工作。我不会丢失局部更改，所以我可以在不重写代码的情况下提交

我犯了完全相同的错误，并设法在不丢失更改的情况下取回了我的回购。

我不知道这是否适用于其他人，因为腐败的原因可能是多方面的，但值得一试

I:

为以防万一，对损坏的git存储库进行了多次备份 从远程存储库克隆最近的推送版本 从损坏的。git文件夹中复制了所有文件，除了所有与HEAD, FETCH_HEAD, ORG_HEAD等相关的文件…最重要的是refs, obj和index 最终得到了一个有效的历史记录，但腐败的索引，应用了这篇文章的解决方案如何解决“错误:坏索引-致命:索引文件腐败”时使用Git

我的存储库又开始工作了……

为了确保我没有推送任何错误，我再次从远程复制，检出我想要从恢复的存储库保存的更改，并将它们提交为新的。