如何恢复硬盘故障损坏的Git对象？

92

我的硬盘出现故障，导致Git存储库的某些文件损坏。运行时，git fsck --full我得到以下输出：

error: .git/objects/pack/pack-6863e0a0e4b4ded6090fac5d12eba6ca7346b19c.pack SHA1 checksum mismatch
error: index CRC mismatch for object 6c8cae4994b5ec7891ccb1527d30634997a978ee from .git/objects/pack/pack-6863e0a0e4b4ded6090fac5d12eba6ca7346b19c.pack at offset 97824129
error: inflate: data stream error (invalid code lengths set)
error: cannot unpack 6c8cae4994b5ec7891ccb1527d30634997a978ee from .git/objects/pack/pack-6863e0a0e4b4ded6090fac5d12eba6ca7346b19c.pack at offset 97824129
error: inflate: data stream error (invalid stored block lengths)
error: failed to read object 0dcf6723cc69cc7f91d4a7432d0f1a1f05e77eaa at offset 276988017 from .git/objects/pack/pack-6863e0a0e4b4ded6090fac5d12eba6ca7346b19c.pack
fatal: object 0dcf6723cc69cc7f91d4a7432d0f1a1f05e77eaa is corrupted

我有存储库的备份，但是包含打包文件的唯一备份已经损坏了。因此，我认为我必须找到一种从不同备份中检索单个对象的方法，并以某种方式指示Git生成仅包含正确对象的新包。

您能给我提示如何修复我的存储库吗？

git corruption data-recovery

— 基督教
source

2

这只是发生在我身上。我不想弄乱git对象...因此将项目从远程存储库重新克隆到新文件夹中，然后仅将问题存储库中的所有文件（.git当然不包括文件夹）复制到新克隆的存储库中...然后git status在新存储库中进行了... git正确检测到对文件的所有受影响的更改，因此我可以重新开始工作。

— 罗迪·卡西姆

82

在以前的某些备份中，您的不良对象可能已经包装在不同的文件中，或者可能是松散的对象。因此，您的对象可能会被恢复。

您的数据库中似乎有一些不良对象。因此，您可以手动进行操作。

由于的缘故git hash-object，git mktree并且git commit-tree不要写对象，因为它们在包中找到了，然后开始这样做：

mv .git/objects/pack/* <somewhere>
for i in <somewhere>/*.pack; do
  git unpack-objects -r < $i
done
rm <somewhere>/*

（您的包已从存储库中移出，并再次在其中解包；现在，数据库中只有好的对象）

你可以做：

git cat-file -t 6c8cae4994b5ec7891ccb1527d30634997a978ee

并检查对象的类型。

如果类型是blob：从以前的备份中检索文件的内容（使用git show或git cat-file或git unpack-file；那么您可以git hash-object -w在当前存储库中重写对象。

如果类型为tree：您可以用来git ls-tree从以前的备份中恢复树；然后git mktree将其再次写入您当前的存储库中。

如果类型为提交：与同git show，git cat-file和git commit-tree。

当然，在开始此过程之前，我会备份您的原始工作副本。

另外，看看如何恢复损坏的Blob对象。

— 丹尼尔·范朱尔
source

1

谢谢，救了我！我将把我的确切步骤作为单独的答案发布。

— 基督教徒

只是一个更正：for命令以“ done”而不是“ end”结尾。

— 费利佩

我正在尝试执行此操作，但它.git/objects/pack/是空的

— kirill_igum 2012年

对我来说; git unpack-objects -r <$ i后失踪了

— mithrandir 2014年

@mithrandir：如果在上一行中输入“ done”：是的，您需要使用分号。如果您输入的正是我写的内容，那么您不会输入。

— Daniel Fanjul 2014年

38

Banengusk使我走上了正轨。作为进一步参考，我想发布我修复存储库损坏所采取的步骤。我很幸运地在较旧的包或存储库备份中找到了所有需要的对象。

# Unpack last non-corrupted pack
$ mv .git/objects/pack .git/objects/pack.old
$ git unpack-objects -r < .git/objects/pack.old/pack-012066c998b2d171913aeb5bf0719fd4655fa7d0.pack
$ git log
fatal: bad object HEAD

$ cat .git/HEAD 
ref: refs/heads/master

$ ls .git/refs/heads/

$ cat .git/packed-refs 
# pack-refs with: peeled 
aa268a069add6d71e162c4e2455c1b690079c8c1 refs/heads/master

$ git fsck --full 
error: HEAD: invalid sha1 pointer aa268a069add6d71e162c4e2455c1b690079c8c1
error: refs/heads/master does not point to a valid object!
missing blob 75405ef0e6f66e48c1ff836786ff110efa33a919
missing blob 27c4611ffbc3c32712a395910a96052a3de67c9b
dangling tree 30473f109d87f4bcde612a2b9a204c3e322cb0dc

# Copy HEAD object from backup of repository
$ cp repobackup/.git/objects/aa/268a069add6d71e162c4e2455c1b690079c8c1 .git/objects/aa
# Now copy all missing objects from backup of repository and run "git fsck --full" afterwards
# Repeat until git fsck --full only reports dangling objects

# Now garbage collect repo
$ git gc
warning: reflog of 'HEAD' references pruned commits
warning: reflog of 'refs/heads/master' references pruned commits
Counting objects: 3992, done.
Delta compression using 2 threads.
fatal: object bf1c4953c0ea4a045bf0975a916b53d247e7ca94 inconsistent object length (6093 vs 415232)
error: failed to run repack

# Check reflogs...
$ git reflog

# ...then clean
$ git reflog expire --expire=0 --all

# Now garbage collect again
$ git gc       
Counting objects: 3992, done.
Delta compression using 2 threads.
Compressing objects: 100% (3970/3970), done.
Writing objects: 100% (3992/3992), done.
Total 3992 (delta 2060), reused 0 (delta 0)
Removing duplicate objects: 100% (256/256), done.
# Done!

— 基督教
source

3

补充说明：如果备份中某个文件包中缺少文件，则从文件包中删除Blob的正确方法是'git cat-file blob <SHA1>> file.dat'，然后将其恢复到损坏的文件中回购，执行“ git hash-object -w file.dat”，如丹尼尔的回答。

— 埃米尔·斯特尔克

您如何找到最后一个未损坏的包装？谢谢

— Romain Ourgorry '16

18

首先尝试以下命令（如果需要，请再次运行）：

$ git fsck --full
$ git gc
$ git gc --prune=today
$ git fetch --all
$ git pull --rebase

然后您仍然遇到问题，请尝试执行以下操作：

删除所有损坏的对象，例如

fatal: loose object 91c5...51e5 (stored in .git/objects/06/91c5...51e5) is corrupt
$ rm -v .git/objects/06/91c5...51e5

删除所有空对象，例如

error: object file .git/objects/06/91c5...51e5 is empty
$ find .git/objects/ -size 0 -exec rm -vf "{}" \;

通过以下方式检查“链接断开”消息：
```
git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
```
这将告诉您损坏的Blob来自哪个文件！
恢复文件，您可能真的很幸运，并且它可能是您已经在工作树中检出的版本：
```
git hash-object -w my-magic-file
```
再次，如果它输出缺少的SHA1（4b945 ..），您现在就完成了！
假设它是某个较旧的版本被破坏，最简单的方法是：
```
git log --raw --all --full-history -- subdirectory/my-magic-file
```
然后将向您显示该文件的整个日志（请注意，您拥有的树可能不是顶级树，因此您需要自己确定它所在的子目录），然后可以重新创建再次缺少带有散列对象的对象。
获取所有缺少提交，树或斑点的裁判的列表：
```
$ git for-each-ref --format='%(refname)' | while read ref; do git rev-list --objects $ref >/dev/null || echo "in $ref"; done
```
可能无法使用常规branch -d或tag -d命令删除其中一些引用，因为如果git注意到损坏，这些引用将死亡。因此，请改用管道命令git update-ref -d $ ref。请注意，在本地分支的情况下，此命令可能会将陈旧的分支配置保留在.git / config中。可以手动将其删除（查找[branch“ $ ref”]部分）。
清除所有引用之后，reflog中仍然可能有断提交。您可以使用git reflog expire --expire = now --all清除所有reflog。如果您不想丢失所有参考记录，则可以在各个参考中搜索破碎的参考记录：
```
$ (echo HEAD; git for-each-ref --format='%(refname)') | while read ref; do git rev-list -g --objects $ref >/dev/null || echo "in $ref"; done
```
（注意，在git rev-list中添加了-g选项。）然后，对每一个使用git reflog expire --expire = now $ ref。当所有损坏的引用和引用日志都消失后，请运行git fsck --full来检查存储库是否干净。晃来晃去的物体还可以。

在下面，您可以找到命令的高级用法，如果使用不当，可能会导致git存储库中的数据丢失，因此请进行备份，然后再不小心对git造成损害。如果您知道自己在做什么，请自担风险。

在获取后将当前分支拉到上游分支的顶部：

$ git pull --rebase

您也可以尝试签出新分支并删除旧分支：

$ git checkout -b new_master origin/master

要在git中找到要删除的损坏对象，请尝试以下命令：

while [ true ]; do f=`git fsck --full 2>&1|awk '{print $3}'|sed -r 's/(^..)(.*)/objects\/\1\/\2/'`; if [ ! -f "$f" ]; then break; fi; echo delete $f; rm -f "$f"; done

对于OSX，请使用sed -E代替sed -r。

另一个想法是从打包文件中解压缩所有对象，以重新生成.git / objects内的所有对象，因此请尝试在存储库中运行以下命令：

$ cp -fr .git/objects/pack .git/objects/pack.bak
$ for i in .git/objects/pack.bak/*.pack; do git unpack-objects -r < $i; done
$ rm -frv .git/objects/pack.bak

如果上述方法没有帮助，您可以尝试rsync或从另一个仓库复制git对象，例如

$ rsync -varu git_server:/path/to/git/.git local_git_repo/
$ rsync -varu /local/path/to/other-working/git/.git local_git_repo/
$ cp -frv ../other_repo/.git/objects .git/objects

要尝试在结帐时修复断开的分支，如下所示：

$ git checkout -f master
fatal: unable to read tree 5ace24d474a9535ddd5e6a6c6a1ef480aecf2625

尝试将其删除并再次从上游签出：

$ git branch -D master
$ git checkout -b master github/master

如果git使您进入分离状态，请签出master并将其合并到分离分支中。

另一个想法是递归地对现有的母版进行基础：

$ git reset HEAD --hard
$ git rebase -s recursive -X theirs origin/master

也可以看看：

— Kenorb
source

2

这是我从损坏的Blob对象中恢复的步骤。

1）识别损坏的Blob

git fsck --full
  error: inflate: data stream error (incorrect data check)
  error: sha1 mismatch 241091723c324aed77b2d35f97a05e856b319efd
  error: 241091723c324aed77b2d35f97a05e856b319efd: object corrupt or missing
  ...

腐败的Blob为241091723c324aed77b2d35f97a05e856b319efd

2）将损坏的Blob移到安全的地方（以防万一）

mv .git/objects/24/1091723c324aed77b2d35f97a05e856b319efd ../24/

3）获取腐败的Blob的父代

git fsck --full
  Checking object directories: 100% (256/256), done.
  Checking objects: 100% (70321/70321), done.
  broken link from    tree 0716831e1a6c8d3e6b2b541d21c4748cc0ce7180
              to    blob 241091723c324aed77b2d35f97a05e856b319efd

父哈希为0716831e1a6c8d3e6b2b541d21c4748cc0ce7180。

4）获取与损坏的blob相对应的文件名

git ls-tree 0716831e1a6c8d3e6b2b541d21c4748cc0ce7180
  ...
  100644 blob 241091723c324aed77b2d35f97a05e856b319efd    dump.tar.gz
  ...

在备份或上游git存储库中找到此特定文件（在我的情况下为dump.tar.gz）。然后将其复制到本地存储库中的某个位置。

5）在git对象数据库中添加以前损坏的文件

git hash-object -w dump.tar.gz

6）庆祝！

git gc
  Counting objects: 75197, done.
  Compressing objects: 100% (21805/21805), done.
  Writing objects: 100% (75197/75197), done.
  Total 75197 (delta 52999), reused 69857 (delta 49296)

— 乔纳森·迈姆
source

这对我不起作用。步骤4导致git ls-tree 9504a07fb803edfdf0c1dd99c5d561274af87982 error: Could not read 19505205fd1f219993da9b75846fff3cf432152d，并且我也没有步骤2再次尝试了整个过程，结果

git ls-tree 9504a07fb803edfdf0c1dd99c5d561274af87982 error: inflate: data stream error (invalid stored block lengths) fatal: failed to read object 19505205fd1f219993da9b75846fff3cf432152d: Invalid argument

— Ryan

1

Git签出实际上可以从修订中挑选单个文件。只要给它提交哈希值和文件名即可。更详细的信息在这里。

我猜想最安全地解决此问题的最简单方法是还原到最新的未提交备份，然后有选择地从较新的提交中选择未损坏的文件。祝好运！

— 蒂姆·林
source

1

如果您的备份已损坏，或者您还有一些部分损坏的备份，则以下两个功能可能会有所帮助（如果您备份损坏的对象，则可能会发生这种情况）。

在您要恢复的仓库中运行两个。

标准警告：仅当您确实绝望并且已备份（损坏的）存储库时使用。这可能无法解决任何问题，但至少应突出显示腐败程度。

fsck_rm_corrupted() {
    corrupted='a'
    while [ "$corrupted" ]; do
        corrupted=$(                                  \
        git fsck --full --no-dangling 2>&1 >/dev/null \
            | grep 'stored in'                          \
            | sed -r 's:.*(\.git/.*)\).*:\1:'           \
        )
        echo "$corrupted"
        rm -f "$corrupted"
    done
}

if [ -z "$1" ]  || [ ! -d "$1" ]; then
    echo "'$1' is not a directory. Please provide the directory of the git repo"
    exit 1
fi

pushd "$1" >/dev/null
fsck_rm_corrupted
popd >/dev/null

和

unpack_rm_corrupted() {
    corrupted='a'
    while [ "$corrupted" ]; do
        corrupted=$(                                  \
        git unpack-objects -r < "$1" 2>&1 >/dev/null \
            | grep 'stored in'                          \
            | sed -r 's:.*(\.git/.*)\).*:\1:'           \
        )
        echo "$corrupted"
        rm -f "$corrupted"
    done
}

if [ -z "$1" ]  || [ ! -d "$1" ]; then
    echo "'$1' is not a directory. Please provide the directory of the git repo"
    exit 1
fi

for p in $1/objects/pack/pack-*.pack; do
    echo "$p"
    unpack_rm_corrupted "$p"
done

— go2null
source

0

我已解决此问题，以添加一些更改，例如git add -A和git commit再次。

— 德米特里（Dmitriy S）
source