如何修复 Git 错误“目标文件 ... 为空”？

Posted 2023-02-19

【中文标题】如何修复 Git 错误“目标文件 ... 为空”？

【英文标题】：How can I fix the Git error "object file ... is empty"?

【发布时间】：2016-11-01 00:02:32

【问题描述】：

当我尝试提交更改时，我收到此错误：

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 add 操作？你的硬盘满了吗？

不行，我的硬盘没满，我不记得我强杀了一个git add操作，万一我杀了呢？我该如何解决这个问题？

不，错误仍然存​​在...

如果此存储库存在于远程存储库中，如果远程存储库中存在该文件，您可以尝试将该文件从那里复制到本地。

当我在 .git 目录中的权限以某种方式搞砸并且我没有读取权限时，我收到了这个错误。因此，它可能发生在文件不为空但无法写入的情况下。修复权限并运行 git fsck 处理了它。

【参考方案1】：

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

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

致 Git 向导，如果这是一个不好的修复方法，请发表评论。但是，它确实对我有用……至少是暂时的。

第 1 步：备份文件夹 .git（实际上，我会在更改某些内容的每个步骤之间进行此操作，但使用新的复制名称，例如 .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。失败，因为我的 HEAD 坏了。

git reflog

fatal: bad object HEAD

第 6 步：谷歌。查找this。手动获取reflog的最后两行：

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

f2d4c4868ec7719317a8fce9dc18c4f2e00ede04 9f0abf890b113a287e10d56b66dbab66adc1662d Nathan VanHoudnos <[e-mail]> 1347306977 -0400    commit: up to p. 24, including correcting spelling of my name
9f0abf890b113a287e10d56b66dbab66adc1662d af9fc0c5939eee40f6be2ed66381d74ec2be895f Nathan VanHoudnos <[e-mail]> 1347358589 -0400    commit: fixed up to page 28

第 7 步：请注意，从第 6 步中我们了解到 HEAD 当前指向最后一次提交。所以让我们试着只看一下父提交：

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 指针似乎来自（现已过时的）索引文件 (source)。所以我杀死了它并重置了存储库。

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

dangling blobs are not errors。我不关心master.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

【讨论】：

嗯，我的笔记本电脑在 git 操作期间死了（SparkleShare 试图在它死时提交我的笔记），然后回购以这种方式损坏。我按照您的步骤一直到 6，但似乎最后几次提交实际上应该是我删除的空目标文件的一部分？事实上，最后 3 次提交基本上完全被破坏了，所以我想我无能为力。幸运的是，我实际上并不需要 SparkleShare 的单个提交，我可以将脏文件从一台机器复制到另一台机器并合并。

谢谢，我学到了很多关于 git 功能的知识，同时也将我的培根保存在一个重要的提交上！巧合的是，这也是因为笔记本电脑的电池电量不足。

我们能给这个人一个诺贝尔奖什么的吗？当我的可移动设备被意外移除时，我弄得一团糟，我很惊讶我能用这个食谱把它清理干净。你摇滚！

如果错误在第 11 步（对于 git fsck --name-object）之后仍然存在，例如 git broken link from tree 61d013* to blob，则可能需要按照 ***.com/a/11959590/2062965 上的说明进行操作 - 它为我解决了问题。

我可以用cd ~; mkdir recovered; cd recovered; git init; git remote add damaged path/to/damaged; git fetch damaged 提出第13 步。在这些步骤之后，git-rebase 相关损坏期间的一些功率损失仍然会导致问题。但是使用更干净的存储库，您会丢失悬空对象，这可能很重要，也可能不重要（它们在 Gerrit 工作流程中很常见），但至少所有本地分支都已恢复。执行额外的步骤将未跟踪和忽略的文件从损坏的存储库复制到新存储库也可能会有所帮助。但真的，谢谢你！

【参考方案2】：

Git 对象文件已损坏（正如其他答案中所指出的那样）。这可能发生在机器崩溃等期间。

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

（请务必先备份您的 Git 存储库文件夹！）

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

这将首先删除任何导致存储库整体损坏的空对象文件，然后获取丢失的对象（以及最新的更改）远程存储库，然后执行完整的对象存储检查。在这一点上，应该会成功且没有任何错误（但可能仍然有一些警告！）

PS。此答案表明您拥有 Git 存储库的远程副本 在某个地方（例如在 GitHub 上），损坏的存储库是与仍然完好无损的远程存储库相关联的本地存储库。如果不是这种情况，请不要尝试按照我推荐的方式进行修复。

【讨论】：

感谢您，我非常虔诚地推送到我的远程分支机构，您的解决方案对我有用。我首先在下面尝试了@mCorr，但是在我提交了新文件后，repo 恢复为损坏状态。这种方法解决了它

在关闭我正在使用 git repo 的 VM 后遇到此问题。这个解决方案效果很好。

感谢 Martin，出色而紧凑的解决方案。尽管我可能会将 PS 放在首位，并以粗体显示警告，以防止天真的用户在本地设置上尝试相同的操作。像 Giscard 一样，关闭虚拟机时会出现这种情况……如果我找到比每次都这样做更持久的解决方案，我会更新。

VM 迷恋也对我的本地 git 存储库执行此操作，我可以确认此解决方案在这种情况下 100% 有效

这是一个比其他方法更快的修复方法。谢谢。

【参考方案3】：

当我推送我的提交并且我的计算机挂起时，这个错误发生在我身上。

我就是这样解决的。

---

修复步骤

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 以显示我的最后两个提交哈希。

git update-ref HEAD 7221fa02cb627470db163826da4265609aba47b2

我选择最后一个commit hash

git status

它将我的所有文件显示为已删除，因为我删除了.git/index 文件

git reset

继续重置

git status

验证我的修复

【参考方案4】：

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

令我失望的是，即使文件系统实施了日志和其他“事务”技术来保持文件系统正常，Git 也可能由于电源故障或设备上的空间。

【讨论】：

我确信上面的答案在技术上更好，但它在第 6 步停止工作，并且在技术上超出了我的想象。权宜之计是 git pull

我遇到了这样一种情况，在执行 Nathan 回答中的说明的步骤 1-11 之后（效果很好！），我遇到了一个错误，即 refs/origin/master 和 refs/origin/ head 没有定义（或类似的东西）。 git pull 解决了这个问题。所以我认为这两种解决方案可以协同工作。

我知道使用的文件系统通常只记录元数据。您也可以为数据打开日志，但我猜它不是默认的，因为开销（？）这可能是文件为空的原因......并且文件系统通常观察每个文件的事务，而 git 有多个文件被修改每个事务，因此即使 fs 保持每个文件的一致性，如果 git 没有，那么我猜 git 会导致不一致的状态......

这个答案对我有用，其他答案太复杂了。

比接受的答案更快的解决方案。对于已经滚动到这里的每个人，如果您赶时间，请按照此答案。

【参考方案5】：

我只是遇到了同样的问题：在拉取远程存储库后，当我执行git status 时，我得到了：

“错误：目标文件 (...) 为空” “致命：松散对象（...）已损坏”

我解决这个问题的方法是：

git stash 错误删除 Git 文件（我不确定是否有必要） git stash clear

我不知道到底发生了什么，但那些指示似乎让一切都变得干净了。

【讨论】：

我总是喜欢更简单的答案 :) 对于此处的第 2 步，我使用了@Nathan VanHoudnos 的答案中提供的命令：cd .git/ && find . -type f -empty -delete

【参考方案6】：

因为我必须定期重启我的VM，所以这个问题经常发生在我身上。几次之后，我意识到我不能每次发生这种情况时都重复这个过程described by Nathan Vanhoudnos，尽管它总是有效的。然后我想出了以下更快的解决方案。

第 1 步

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

mv current_repository temp_repository

第 2 步

再次从源克隆存储库。

git clone source_to_current_repository.git

第 3 步

删除新存储库下的 Everything，除了 .git 文件夹。

第 4 步

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

第 5 步

删除 temp_repository，我们就完成了。

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

【讨论】：

或者不要移动你当前的仓库，1）创建一个新的克隆git clone source_to_current_repo.git clean_repo，2）备份旧的.git文件夹，3）复制干净的.git文件夹。

你是对的。我现在已经做到了。稍后将编辑答案。

@haoqiang：你写的“因为我必须定期重启我的虚拟机，所以这个问题经常发生在我身上。”我们也有同样的经历。您是否在根本原因上取得了任何进展 - 使问题发生频率降低的 VM 设置？

【参考方案7】：

移动您的应用文件夹以进行备份，即 mv app_folder app_folder_bk（它就像一个 git stash） git clone your_repository 最后，打开一个合并工具（我在 Linux 上使用 Meld 差异查看器或在 Windows 上使用 WinMerge）并将更改从右侧 (app_folder_bk) 复制到左侧 (new app_folder）（就像 git stash apply）。

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

【讨论】：

当您将所有本地更改推送到上游，或者更改很少，因此克隆比恢复更快时，您应该这样做。

【参考方案8】：

我在使用虚拟机时经常遇到这个问题。

对我来说，以下作品：

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

如果您想节省一些下载 - 进入您的文件资源管理器并删除文件夹中已提交的所有文件并保留在您的 /vendor 和 /node_modules（我使用 php Composer 和 npm）文件夹。

然后只需创建一个新的存储库：

git init

添加您的遥控器

git remote add origin ssh://[e-mail]/YourUsername/repoName.git

并获取分支/全部

git fetch origin somebranch

然后检查一下

git checkout somebranch

那么你应该在错误之前的那一点。

【参考方案9】：

这解决了我的问题：

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

【讨论】：

这有帮助。谢谢。

如果repo是干净的，你只需要“cd .git/ && find . -type f -empty -delete && cd - && git pull”，你可能需要checkout @中的一些文件987654322@，因为有些是空的。

【参考方案10】：

在一个脚本中

#! /bin/sh

# Save Git data
cp -r .git gitold

# Remove all empty Git object files
find .git -type f -empty -delete -print

# Get the current branch name
branchname=$(git branch --show-current)

# Get the latest commit hash
commit=$(tail -2 .git/logs/refs/heads/$branchname | awk ' print $2 ' | tr -d '[:space:]')

# Set HEAD to this latest commit
git update-ref HEAD $commit

# Pull the latest changes on the current branch (considering remote is origin)
git pull origin $branchname

echo "If everything looks fine you remove the git backup running :\n\
      $ rm -rf gitold \n\
Otherwise restore it with: \n\
      $ rm -rf .git; mv gitold .git"

【参考方案11】：

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

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

git checkout -b backup-branch # 创建备份分支 git reset --hard HEAD~4 # 重置为一切正常的提交。就我而言，我必须在头部支持四个提交，直到我的头部处于输入提交消息之前的位置。

在执行此步骤之前，复制您将重置的提交的哈希值。就我而言，我复制了最后四次提交的哈希

。 git cherry-pick <commit-hash> # Cherry 选择从旧分支到新分支的重置提交（在我的情况下是四个提交，所以我做了四次）。 git push origin backup-branch # 推送新分支以确保一切正常 git branch -D your-branch # 删除本地分支（'your-branch'是有问题的分支） git push origin :your-branch # 从远程删除分支 git branch -m backup-branch your-branch # 将备份分支重命名为有问题的分支的名称 git push origin your-branch #推送新分支 git push origin :backup-branch # 从远程删除备份分支

【讨论】：

步骤很多！

【参考方案12】：

让我们变得简单...仅适用于您将源代码上传到远程 Git 存储库的情况

备份你的 .git 文件夹

检查您的 Git 存储库

 git fsck --full

删除空对象文件（全部）

 rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e

再次检查您的 Git 存储库。

 git fsck --full

从远程 Git 存储库中提取您的源代码

 git pull origin master

【参考方案13】：

我和我的同事多次遇到同样的问题，为了解决这个问题，我们只需执行我在下面描述的步骤。这不是可以找到的最优雅的解决方案，但它可以在不丢失数据的情况下工作。

重命名当前工作目录。 （此示例为old_project）。 使用 git clone 在新目录中克隆存储库。 在命令行中，将工作目录更改为新创建的项目，并切换到您一直在处理的分支。 将old_project内的所有文件和目录（.git目录除外）复制到新创建的项目目录中。 检查您的工作树状态（请注意，更改比您预期的要多），然后提交更改。

希望对你有帮助……

【参考方案14】：

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

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

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

2>&1 将错误消息重定向到标准输出以便能够 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

在运行git fsck --full时摆脱error: HEAD: invalid reflog entry $blubb。

【参考方案15】：

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

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

【参考方案16】：

这是处理这个问题的一种非常简单快捷的方法如果你有一个本地仓库，里面有你需要的所有分支和提交，如果你可以创建一个新的仓库（或删除服务器的 repo 并在其位置创建一个新的）：

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

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

如果您在 repo 上有合作者，那么我认为在许多情况下，您的合作者所要做的就是更改其本地 repo 的远程 URL，并可选择推送他们拥有的服务器没有的任何提交。

当我遇到同样的问题时，这个解决方案对我有用。我有一个合作者。在我将本地 repo 推送到新的远程 repo 后，他只需将本地 repo 更改为指向远程 repo URL，一切正常。

【参考方案17】：

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

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

【参考方案18】：

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

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

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

在应用此方法之前记得备份。

【参考方案19】：

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

你基本上只是用一个干净的目录替换损坏的.git/ 目录。

假设您的项目的以下目录包含损坏的 Git 文件：projects/corrupt_git/

cp projects/corrupt_git projects/backup - （可选）进行备份 git clone [repo URL] projects/clean_git - 这样你就得到了projects/clean_git rm -rf corrupt_git/.git/ - 删除损坏的 .git 文件夹 mv clean_git/.git/ corrupt_git/ - 将干净的 git 移至 corrupt_git/.git git status in projects/corrupt_git - 确保它有效

【参考方案20】：

这也几乎经常发生在我身上。当这种情况完全发生时，我还没有制定协议，但我怀疑每当我的virtual machine（VM）“意外”存在时就会发生这种情况。如果我关闭虚拟机窗口（我正在使用Ubuntu 18.04（仿生海狸））并重新开始，事情总是（？）工作。但是如果我的笔记本电脑关闭时VM窗口仍然打开（Win​​dows主机系统），那么我会经常遇到这个问题。

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

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

由于根本问题不是真正的 Git 问题，而是 VM 和/或 Linux 问题，我想知道是否应该有一种方法可以治愈原因而不是症状？这种错误不是表明某些文件系统更改没有在任何合理的时间内“应用”，而只是缓存？ （例如Are file edits in Linux directly saved into disk?）——在我看来，虚拟 Linux 机器似乎没有足够频繁地同步它们的东西。这是 Oracle 的 VirtualBox（否则工作得非常好）或来宾文件系统的问题，还是我们都忽略的某些设置的问题，超出了我的专业知识。但如果有人能阐明这一点，我会很高兴。

【参考方案21】：

将所有内容（在包含 .git 文件夹的文件夹中）复制到备份，删除所有内容，然后重新启动。确保你手边有 Git 遥控器：

git remote -v
 origin    [e-mail]:rwldrn/idiomatic.js.git (fetch)
 origin    [e-mail]:rwldrn/idiomatic.js.git (push)

然后

mkdir mygitfolder.backup
cp mygitfolder/* mygitfolder.backup/
cd mygitfolder
rm -r * .git*
git init
git remote add origin [e-mail]:rwldrn/idiomatic.js.git

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

【讨论】：

rm -rf * 可能会产生非常糟糕的后果。你真的是那个意思吗？

@tommyk 因此首先复制到备份。我想武力是没有必要的。

【参考方案22】：

从干净的分支中签出 master 后，我遇到了同样的问题。

过了一会儿，我发现master中有很多修改过的文件。我不知道他们为什么从一个干净的分支切换到那里。无论如何，因为修改后的文件对我来说毫无意义，我只是把它们藏起来，错误就消失了。

git:(master) git stash

【参考方案23】：

十二步解决方案covered by Nathan VanHoudnos 也帮助我摆脱了困境。谢谢。关键步骤是输入：

git fsck --full

并删除所有空对象

rm .git/objects/...

然后得到flog的两行：

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

带有返回值

git update-ref HEAD ...

此时我没有更多错误，所以我备份了我最近的文件。然后执行 Git 拉取，然后执行 Git 推送。我将备份复制到我的 Git 存储库文件并进行了另一个 Git 推送。这让我了解最新情况。

【参考方案24】：

如果您有一个旧备份并且很着急：

为您当前的 Git 损坏的项目路径创建一个新备份。

将您的 .git 移至回收站（永不删除） 从旧备份中复制.git git pull（会造成合并冲突） 将所有源（放入 Git 中的所有内容）移至回收站：./src（永不删除） 从新备份中复制所有源代码（放入 Git 中的所有内容） 在git gui 接受所有“合并”，然后按一下……拍手！

【参考方案25】：

其实我也有同样的问题。

在尝试此操作之前，请拥有您的代码副本。

我刚刚做了 git reset HEAD~

我最后一次提交被撤消了。然后我又犯了，问题解决了！

【参考方案26】：

在我的VM 崩溃并且 Git 文件损坏后，我遇到了同样的问题。

第一步，从项目的根文件夹开始。

find .git/objects -type f -empty -delete

然后是修剪和提取......

git prune
git fetch --all --prune

还有一些回滚，它开始工作了。

【参考方案27】：

在这种情况下，我通过关注这个问题来解决我的问题。

从我的存储库目录中删除 .git 文件夹。 （为安全起见保留备份） 将我的 repo 克隆到另一个目录。 从新的克隆目录复制 .git 文件夹。 粘贴到我之前出现问题的目录中。

检查 git 状态，希望你能看到你的所有变化。现在你可以提交和推送了。