如何修复GIT错误：目标文件为空？

当我尝试提交更改时，出现以下错误：

error: object file .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0 is empty
fatal: loose object 3165329bb680e30595f242b7c4d8406ca63eeab0 (stored in .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0) is corrupt

任何想法如何解决此错误？

编辑

我试过git fsck了

error: object file .git/objects/03/dfd60a4809a3ba7023cbf098eb322d08630b71 is empty
fatal: loose object 03dfd60a4809a3ba7023cbf098eb322d08630b71 (stored in .git/objects/03/dfd60a4809a3ba7023cbf098eb322d08630b71) is corrupt

我有一个类似的问题。我的笔记本电脑在git操作期间电量耗尽。嘘

我没有任何备份。（注意，Ubuntu One不是git的备份解决方案；它将用损​​坏的存储库有帮助地覆盖您的健全存储库。）

对于git向导，如果这是修复它的不好方法，请发表评论。但是，它确实为我工作了……至少是暂时的。

步骤1：备份.git（实际上，我在每次更改后的步骤之间都执行此操作，但要使用新的复制到名称，例如.git-old-1，.git-old-2等）。 ：

cp -a .git .git-old

步骤2：执行 git fsck --full

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ 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：删除空文件。我想通了。还是空白。

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ 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开始告诉我它实际上是在处理对象目录：

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ 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实际运行：

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ 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。失败，因为我的头坏了。

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git reflog
fatal: bad object HEAD

步骤6：Google。找到这个。手动获取reflog的最后两行：

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ 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当前指向最后的提交。因此，让我们尝试仅查看父提交：

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ 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。

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git update-ref HEAD 9f0abf890b113a287e10d56b66dbab66adc1662d

哪个没抱怨。

步骤9：看看fsck怎么说：

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ 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指针似乎是来自（现已过时）索引文件（source）的。所以我杀了它并重置了仓库。

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ rm .git/index
nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ 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 ...

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ 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

在晃来晃去斑点不是错误。我不关心master.u1冲突，现在它可以正常工作了，我不想再碰它了！

第12步：掌握本地编辑信息：

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ 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")


nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git commit -a -m "recovering from the git fiasco"
[master 7922876] recovering from the git fiasco
 3 files changed, 12 insertions(+), 94 deletions(-)

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git add tex/sept2012_code/example-code-testing.R
nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ 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

因此，希望将来对人们有用。我很高兴它奏效。

git对象文件已损坏（也如其他答案所指出）。这可能在机器崩溃等情况下发生。

我有同样的事情。在阅读了其他最佳答案之后，我发现了使用以下命令修复损坏的git存储库的最快方法（在包含该.git文件夹的git工作目录中执行）：

（请务必先备份您的git repository文件夹！）

find .git/objects/ -type f -empty | xargs rm
git fetch -p
git fsck --full

这将首先删除所有导致整个存储库损坏的空对象文件，然后从远程存储库中获取丢失的对象（以及最新更改），然后进行完整的对象存储检查。在这一点上，应该可以成功执行而不会出现任何错误（尽管可能还会有一些警告！）

PS。这个答案表明您在某个地方（例如，在GitHub上）有一个git存储库的远程副本，而损坏的存储库是与仍处于正常状态的远程存储库绑定的本地存储库。如果不是这种情况，请不要尝试按照我的建议进行修复。

当我推动提交并且计算机挂起时，会发生此错误。这就是我解决的方法。

解决步骤

git status

显示空/损坏的目标文件

rm .git/objects/08/3834cb34d155e67a8930604d57d3d302d7ec12

去掉它

git status

我收到fatal: bad object HEAD消息

rm .git/index

我删除了index进行重置

git reset

致命：无法解析对象“ HEAD”。

git status
git pull

只是检查发生了什么

tail -n 2 .git/logs/refs/heads/MY-CURRENT-BRANCH

打印tail -n 2日志分支的最后2行以显示我的最后2行commit hash

git update-ref HEAD 7221fa02cb627470db163826da4265609aba47b2

我选最后一个 commit hash

git status

显示我的所有文件，deleted因为我删除了该.git/index文件

git reset

继续重置

git status

验证我的修复

注意： 当我着陆此问题并将答案用作参考时，便开始执行这些步骤。

我解决了此问题，删除了git fsck检测到的各种空文件，然后运行简单的git pull。

我感到失望的是，即使文件系统也实现了日记功能和其他“事务性”技术来保持fs健全，由于电源故障或设备空间不足，git可能会进入损坏状态（并且无法自行恢复）。

我只是遇到了同样的问题：拉远的存储库后，当我进行git状态时，我得到：“错误：对象文件（...）为空”“致命：松散的对象（...）已损坏”

我解决此问题的方法是：

1. git stash
2. 错误删除git文件（不确定是否有必要）
3. git隐藏

我不知道到底发生了什么事，但是那条指示似乎使一切变得干净。

因为我必须定期重新引导我的VM，所以以某种方式经常会发生此问题。经过几次，我意识到我每次都无法重复@ Nathan-Vanhoudnos所描述的过程，尽管它总是可以的。然后我想出了以下更快的解决方案。

步骤1

将整个仓库移至另一个文件夹。

mv current_repo temp_repo

第2步

再次从源克隆回购。

git clone source_to_current_repo.git

第三步

删除新仓库下的所有东西，除了.git文件夹中。

第四步

将一切从temp_repo到新的回购只是在git的文件夹。

第5步

删除temp_repo，我们完成了。

几次之后，我确定您可以非常快速地执行此过程。

1. mv您的文件夹应用程序进行备份，即mv app_folder app_folder_bk（就像git stash一样）
2. git clone your_repository
3. 最后，。打开一个合并工具（我使用MEL diff Viewer Linux或Winmerge Windows），然后将更改从右（app_folder_bk）复制到左（new app_folder）（就像git stash apply一样）。

就这样。也许这不是最好的方法，但我认为它是如此实用。

就我而言，发生此错误是因为我正在键入提交消息，并且笔记本电脑已关闭。

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

• git checkout -b backup-branch ＃创建一个备份分支
• git reset --hard HEAD~4＃重置为一切正常的提交。在我的情况下，我必须在头部中退回4次提交，即直到我的头部处于键入提交消息之前的位置为止。在执行此步骤之前，请复制您将重置的提交的哈希，在我的情况下，我复制了最后4个提交的哈希
• git cherry-pick <commit-hash> ＃Cherry从旧分支到新分支中选择重置的提交（在我的情况下是4个提交，因此我执行了4次此步骤）。
• git push origin backup-branch ＃推送新分支以确保一切正常
• git branch -D your-branch ＃在本地删除分支（“您的分支”是有问题的分支）
• git push origin :your-branch ＃从远程删除分支
• git branch -m backup-branch your-branch ＃重命名备份分支以使用出现问题的分支的名称
• git push origin your-branch ＃推送新分支
• git push origin :backup-branch ＃从远程删除备份分支

git stash
git checkout master
cd .git/ && find . -type f -empty -delete
git branch your-branch-name -D
git checkout -b your-branch-name
git stash pop

解决我的问题

如果您有一个包含所有需要的分支和提交的本地存储库，并且如果可以创建一个新的存储库（或删除服务器的存储库并创建一个新的存储库），那么这是一种解决此问题的非常简单快捷的方法。在这里）：

1. 在服务器上创建一个新的空仓库（或删除旧仓库并在其位置创建一个新仓库）
2. 更改本地副本的远程URL以指向新存储库的远程URL。
3. 将所有分支从本地存储库推送到新的服务器存储库。

这将保留您在本地存储库中拥有的所有提交历史记录和分支。

如果您在仓库中有协作者，那么我认为在许多情况下，您的所有协作者要做的就是也更改其本地仓库的远程URL，并有选择地推送服务器没有的任何提交。

当我遇到同样的问题时，此解决方案对我有用。我有一个合作者。当我将本地存储库推送到新的远程存储库后，他只是更改了本地存储库以指向远程存储库URL，一切正常。

我假设您有一个已将所有相关更改推送到的遥控器。我不在乎本地更改，只是想避免删除和重新克隆大型存储库。如果您确实有重要的本地更改，则可能需要更加小心。

笔记本电脑崩溃后，我遇到了同样的问题。可能是因为它是一个很大的存储库，所以我有很多损坏的对象文件，在调用时一次只出现一个git fsck --full，所以我写了一个小外壳的一线式外壳自动删除其中一个：

$ sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`

• 2>&1 将错误消息重定向到stdout以便能够grep
• 使用的grep选项：
  • -o 仅返回行中实际匹配的部分
  • -E 启用高级正则表达式
  • -m 1 确保只返回第一个比赛
  • [0-9a-f]{2} 如果两个字符同时出现，则匹配0到9以及a和f之间的任何字符
  • [0-9a-f]* 匹配0到9之间的任意数量的字符，以及a和f一起出现

它仍然一次只删除一个文件，因此您可能需要像这样循环调用：

$ while true; do sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`; done

问题是，它不再输出任何有用的信息，所以您不知道它何时完成（一段时间后它应该什么都不做）

为了解决这个问题，我git fsck --full在每个回合之后添加了一个的调用，如下所示： $ while true; do sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`; git fsck --full; done

现在大约快一半，但是它确实输出“状态”。

在此之后我打了周围的一些与建议，在此线程，终于到了一个地步，我可以git stash和git stash drop很多的坏的东西。

第一个问题解决了

之后，我仍然遇到以下问题：unable to resolve reference 'refs/remotes/origin/$branch': reference broken可以通过以下方法 解决 $ rm \repo.git\refs\remotes\origin\$branch

$ git fetch

然后我做了一个 $ git gc --prune=now

$ git remote prune origin

很好的措施和

git reflog expire --stale-fix --all

error: HEAD: invalid reflog entry $blubb跑步时要摆脱git fsck --full。

让我们简单点..仅在您将源上传到远程git repo的情况下

1. 备份你的.git

2. 检查你的git

   git fsck --full
   

3. 删除空的目标文件（全部）

   rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e
   

4. 再次检查你的git。

   git fsck --full
   

5. 从远程git提取源

   git pull origin master
   

我在虚拟机上经常遇到这个问题。

对我而言，以下作品：

cd /path/to/your/project
rm -rf .git

如果要保存一些下载内容，请进入文件资源管理器并删除已提交的文件夹中的所有文件，然后保留在/ vendor和/ node_modules（我与composer和npm一起使用）文件夹中。

然后创建一个新的仓库

git init

添加您的遥控器

git remote add origin ssh://git@github.com/YourUsername/repoName.git

并获取分支/所有

git fetch origin somebranch

并检查出来

git checkout somebranch

那么您应该在错误之前。

希望这可以帮助。

问候。

我遇到了同样的问题，并且我使用了一种非常简单的方法来解决它。我发现那些丢失的文件存在于队友的计算机上。

我将这些文件一个一个地复制到git服务器（总共9个文件），这解决了问题。

我和我的同事已经多次遇到相同的问题，并且要解决该问题，我们只需执行下面描述的步骤。这不是可以找到的最优雅的解决方案，但可以正常工作而不会丢失数据。

1. 重命名当前工作目录。（old_project对于此示例）。
2. 使用以下命令将存储库克隆到新目录中 git clone。
3. 在命令行上，将工作目录更改为新创建的项目，然后切换到您正在处理的分支。
4. 复制其中的所有文件和目录old_project（.git）到新创建的项目目录中。
5. 检查您的工作树状态（请注意，发生的更改比您预期的要多得多），然后提交更改。

希望对您有帮助...

如果您在github.com上的公共仓库正在运行，但是您的本地仓库已损坏，这是解决问题的一种方法。请注意，您将丢失在本地存储库中所做的所有提交。

好的，所以我在本地有一个object empty error仓库给我这个仓库，在github.com上也有相同的仓库，但是没有这个错误。因此，我所做的只是克隆从github运行的仓库，然后从损坏的仓库（.git文件夹除外）复制所有内容，并将其粘贴到正在工作的克隆仓库中。

这可能不是一个实际的解决方案（因为您删除了本地提交），但是，您维护了代码并修复了版本控制。

在应用此方法之前，请记住备份。

就我而言，保留本地提交历史记录对我而言并不重要。因此，如果这也适用于您，则可以将其作为上述解决方案的快速替代方案：

基本上，您只需将损坏的.git/目录替换为干净的目录即可。

让我们使用损坏的git为您的项目假定以下目录： projects/corrupt_git/

1. cp projects/corrupt_git projects/backup -（可选）进行备份
2. git clone [repo URL] projects/clean_git -这样你就可以 projects/clean_git
3. rm -rf corrupt_git/.git/ -删除损坏的.git文件夹
4. mv clean_git/.git/ corrupt_git/ -将干净的git移至 corrupt_git/.git
5. git status入projects/corrupt_git-确保它起作用

将所有内容（包含.git的文件夹中）复制到备份中，然后删除所有内容并重新启动。确保您拥有方便的git remote：

git remote -v
 origin git@github.com:rwldrn/idiomatic.js.git (fetch)
 origin git@github.com:rwldrn/idiomatic.js.git (push)

然后

mkdir mygitfolder.backup
cp mygitfolder/* mygitfolder.backup/
cd mygitfolder
rm -r * .git*
git init
git remote add origin git@github.com:rwldrn/idiomatic.js.git

然后手动合并所有新文件，并尝试保持计算机电源打开。

从干净的分支中检出master后出现相同的问题。一段时间后，我认识到master中有很多修改过的文件。从干净的分支切换后，我不知道为什么他们会去那里。无论如何，因为修改后的文件对我而言毫无意义，所以我将它们藏起来并且错误消失了。

git:(master) git stash

如果您有旧的备份并且很忙：

对您当前的git-broken项目路径进行新的备份。

1. 将您.git移至垃圾箱（切勿删除）
2. .git从旧备份中 复制
3. git pull （将产生合并冲突）
4. 将所有来源（一切放入git中）移至垃圾箱：（./src 永不删除）
5. 。从新备份中复制所有来源（所有您放入git中的内容）
6. 接受的所有“合并” git gui，推动并拍拍手！

上面介绍的十二步解决方案也使我摆脱了困境。谢谢。关键步骤是输入：

git fsck --full 

并删除所有空对象

rm .git/objects/...

然后得到两行鞭log：

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

与返回值

git update-ref HEAD ...

此时，我没有更多错误了，因此我备份了最近的文件。然后执行git pull，然后执行git push。将我的备份复制到我的git存储库文件中，然后执行另一个git push。那让我很感动。

我修复了我的git错误：目标文件为空：

1. 保存自上次成功提交/推送以来我编辑的所有文件的副本，
2. 删除并重新克隆我的存储库，
3. 用我编辑的文件替换旧文件。

希望这会有所帮助。

我也经常发生这种情况。确切情况下还没有制定协议，但是我怀疑只要我的虚拟机“意外地”存在，它就会发生。如果关闭VM窗口（我正在使用Ubuntu 18.04）并再次启动，则一切总是正常（？）。但是，如果关闭笔记本电脑（Windows主机系统）后，VM窗口仍处于打开状态，则我会经常遇到此问题。

至于这里给出的所有答案：

1. 谢谢-它们非常有用；我通常会保存代码的本地副本，从远程还原存储库，然后将备份副本移回到本地文件夹中。

2. 因为根本的问题实际上不是git问题，而是VM和/或Linux问题，所以我想知道是否应该有办法解决症状而不是解决问题？这种错误是否表示某些文件系统更改在任何合理的时间内没有“应用”，而是仅被缓存了？（例如，请参阅/unix/464184/are-file-edits-in-linux-direct-saved-into-disk）-在我看来，虚拟Linux机器似乎没有足够频繁地同步他们的东西。这是Oracle的VirtualBox（否则效果很好）还是来宾文件系统的问题，还是我们都忽略的某些设置的问题，超出了我的专业知识。但是，如果有人可以阐明这一点，我将很高兴。

其实我有同样的问题。尝试之前，请先获得代码副本。

我已经做了 git reset HEAD~

我的上一次提交被撤消，然后我再次提交了，问题解决了！

警告：有了更多的经验，我意识到这是核选择，通常不应该这样做，也不会教任何东西。但是，在极少数情况下进行个人项目时，我仍然发现它很有用，因此我将其保留。

如果您不在乎保留历史提交，请运行

rm -r .git

然后对任何有关删除写保护文件的问题回答“是”。一分钟内解决问题。