リモートからプルすると、圧縮に関する次のエラーが表示されます。手動圧縮を実行すると、同じ結果になります。

$ git gc
error: Could not read 3813783126d41a3200b35b6681357c213352ab31
fatal: bad tree object 3813783126d41a3200b35b6681357c213352ab31
error: failed to run repack

誰か知っていますか、それについて何をすべきですか？

猫ファイルから私はこれを得ます：

$ git cat-file -t 3813783126d41a3200b35b6681357c213352ab31
error: unable to find 3813783126d41a3200b35b6681357c213352ab31
fatal: git cat-file 3813783126d41a3200b35b6681357c213352ab31: bad file

そしてgit fsckから私はこれを取得します（それが実際に関連しているかどうかはわかりません）：

$ 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 internalsに関するScott ChaconのGit Screencastを。これにより、内部でgitがどのように機能するか、また、本当に行き詰まって他の人からそのオブジェクトを取得できない場合に、この探偵の作業をどのように行うかがわかります。

私は同じ問題を抱えていました（理由はわかりません）。

この修正では、破損していないリポジトリのリモートコピーにアクセスする必要があり、ローカルで作業しているコピーをそのまま維持します。

しかし、いくつかの欠点があります。

• プッシュされなかったコミットの記録は失われ、再コミットする必要があります。
• あなたはすべての隠し場所を失います。

修正

リポジトリの上の親ディレクトリから次のコマンドを実行します（ 'foo'をプロジェクトフォルダーの名前に置き換えます）。

1. 破損したディレクトリのバックアップを作成します。
   cp -R foo foo-backup
2. リモートリポジトリの新しいクローンを新しいディレクトリに作成します。
   git clone git@www.mydomain.de:foo foo-newclone
3. 破損した.gitサブディレクトリを削除します。
   rm -rf foo/.git
4. 新しくクローンした.gitサブディレクトリをfooに移動します。
   mv foo-newclone/.git foo
5. 一時的な新しいクローンの残りを削除します。
   rm -rf foo-newclone

Windowsでは、以下を使用する必要があります。

• copy の代わりに cp -R
• rmdir /S の代わりに rm -rf
• move の代わりに mv

これでfooには元の.gitサブディレクトリが戻りましたが、ローカルの変更はすべてそのまま残っています。git status、commit、pull、push、など、彼らが必要として再び働きます。

あなたの最善の策は、おそらくリモートリポジトリ（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  

次に、必要に応じて変更されたファイルをコミットします。

私のノートブックでVMを使用すると、バッテリーが切れてこのエラーが発生しました。

エラー：オブジェクトファイル.git / objects / ce / theRefが空ですエラー：オブジェクトファイル.git / objects / ce / theRefが空です致命的：ルーズオブジェクトtheRef（.git / objects / ce / theRefに保存されています）が破損しています

2つのコマンドだけで、作業を失うことなく、リポジトリを再び機能させることができました（変更されたファイル/コミットされていない変更）

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

その後、私はを実行しましたgit statusが、レポは問題なく、変更が行われました（コミットされるのを待って、今すぐ実行してください。

gitバージョン1.9.1

このソリューションが機能せず、より根本的なアプローチが必要な場合に備えて、覚えているすべての変更をバックアップしてください。

コミットメッセージを書いている最中にコンピューターがクラッシュしました。再起動後、作業ツリーは以前と同じ状態になり、変更を正常にコミットすることができました。

しかし、実行しようとするgit statusと、

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

他のほとんどの回答とは異なり、私はデータを回復しようとはしていませんでした。空のオブジェクトファイルについて文句を言うのをやめるには、Gitが必要でした。

概観

「オブジェクトファイル」は、あなたが気にする実際のファイルのgitのハッシュ表現です。Gitは、ハッシュされたバージョンのsome/file.whateverされた格納され.git/object/xx/12345、エラーの修正は、ほとんどの場合、「ルーズオブジェクト」がどのファイルを表すことになっていたかを理解することでした。

細部

可能なオプションは

1. 空のファイルを削除する
2. ファイルをGitが受け入れ可能な状態にする

アプローチ1：オブジェクトファイルを削除する

私が最初に試みたのは、オブジェクトファイルを移動することだけです。

mv .git/objects/xx/12345 ..

それはうまくいきませんでした-gitはリンク切れについて不平を言い始めました。アプローチ2に進みます。

アプローチ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は文句を言うのをやめました。

試す

git stash

これでうまくいきました。それはあなたがコミットしていないものを隠し、それが問題を回避しました。

ガベージコレクションは、私の問題を修正します：

git gc --aggressive --prune=now

完了するまで少し時間がかかりますが、すべてのルーズオブジェクトや破損したインデックスが修正されました。

git prune修正済みのこの問題を実行してください

私はちょうどこれを経験しました-Gitリポジトリに書き込み中にマシンがクラッシュし、破損しました。以下のように修正しました。

まず、リモートリポジトリにプッシュしなかったコミットの数を確認することから始めました。

gitk &

このツールを使用しない場合は非常に便利です。私の知る限り、すべてのオペレーティングシステムで使用できます。これは、私のリモコンに2つのコミットがないことを示しています。そのため、最新のリモートコミットを示すラベルをクリックしました（通常、これは/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 logはgitkウィンドウまたはウィンドウから貼り付けることができます）。

patch -p1 < 1.patch
git commit

patch -p1 < 2.patch
git commit

これは私のために物事を復元しました（そして、多くのコミットのためにそれを行うより速い方法がおそらくあることに注意してください）。しかし、破損したリポジトリのツリーを修復できるかどうかを知りたいと思っていました。上記のように利用可能な修復されたレポで、壊れたフォルダーで次のコマンドを実行します。

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エラーなし。レポートにはおそらく「ダングリングコミット」行と「ダングリングブロブ」行があります。これらは、このフォルダーのリベースと修正の結果であり、問​​題ありません。ガベージコレクターは、やがてそれらを削除します。

したがって、（少なくとも私の場合は）ツリーが破損しても、プッシュされていないコミットが失われるわけではありません。

壊れたルーズオブジェクトエラーも発生していました。

./objects/x/x

破損したオブジェクトのディレクトリに移動して、問題を修正しました。そのオブジェクトに割り当てられているユーザーが私のgitユーザーのものではないことがわかりました。どうやって起こったのかはわかりませんが、chown git:gitそのファイルでを実行すると、再び機能しました。

これは一部の人々の問題の潜在的な修正になる可能性がありますが、すべての問題に必要なわけではありません。

私の（windows）マシンが再起動することを決めた後、このエラーが発生しました。ありがたいことに、私のリモートリポジトリは最新の状態だったので、新しいgitクローンを作成しました。

ランニングはgit stash; git stash pop私の問題を修正しました

ここでは他の多くの手順を実行しました。Linusによるgitツリー/オブジェクトの見方と不足しているものを見つける方法の説明は、特に役に立ちました。git-gitが破損したblobを回復する

しかし、結局のところ、私にとっては、部分的なディスク障害によって引き起こされた緩やかな/破損したツリーオブジェクトがあり、ツリーオブジェクトはそのドキュメントで簡単に回復/カバーされません。

最後に、私は競合をobjects/<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  

ちょうどここに事件があった。問題は、破損したファイルの所有権が通常のユーザーではなく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/

それが役に立てば幸い！

私にとってこれは、実行中に停電が原因で起こりました git push。

メッセージは次のようになりました。

$ 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 pushに発生したため、サーバーが更新された後に発生するクライアント側の書き換え中に発生したことは明らかです。私は周りを見回してc2388、私の場合はコミットオブジェクトであることを理解しました.git/refs。だから私は見つけることができることを知っていましたc2388、履歴を見ると（Webインターフェースまたは2番目のクローンを介した。

2番目のクローンでは、git log -n 2 c2388の前身を識別するためにa を実行しましたc2388。その後、私は手動で変更し.git/refs/heads/master、.git/refs/remotes/origin/masterのc2388代わりにの前任者になりましたc2388。その後、私は行うことができますgit fetch。git fetch空のオブジェクト上の競合のために数回失敗しました。git fetch成功するまで、これらの空のオブジェクトをそれぞれ削除しました。これでリポジトリが修復されました。

私はこの方法で解決しました。破損していないオブジェクトファイルをバックアップのクローンから元のリポジトリに単にコピーすることにしました。これもうまくいきました。（ちなみに、名前で.git / objects /にオブジェクトが見つからない場合は、おそらくスペースを節約するために[パック] [パック]されています。）

私の裸のリモートgitリポジトリにも同じ問題がありました。多くのトラブルシューティングの後、同僚の1人が.git / objects内の一部のファイルに444（r--r--r）ではなく440（r--r -----）のアクセス許可があるコミットを行ったことがわかりました-）。裸のgitリポジトリ内の「chmod 444 -Rオブジェクト」で権限を変更するよう同僚に依頼した後、問題は修正されました。

私はこのような問題を抱えていました。私の特定の問題は、最新のコミット（したがって、マスターブランチ）を破壊するシステムクラッシュが原因でした。私はプッシュせず、そのコミットを作り直したいと思っていました。私の特定のケースでは、次のように対処できました。

1. のバックアップを作成し.git/ます。rsync -a .git/ git-bak/
2. を確認.git/logs/HEADし、有効なコミットIDの最後の行を見つけます。私にとって、これは2番目に新しいコミットでした。私はまだファイルの作業ディレクトリバージョンを持っているので、これは良かったので、必要なすべてのバージョンを使用できました。
3. そのコミットでブランチを作成します。 git branch temp <commit-id>
4. 壊れたコミットを作業ディレクトリのファイルで再実行します。
5. git reset master temp 手順2で作成した新しいコミットにマスターブランチを移動します。
6. git checkout masterそして、それがで正しく見えることを確認してくださいgit log。
7. git branch -d temp。
8. git fsck --fullこれで、fsckが検出した破損オブジェクトを削除しても安全です。
9. 問題がなければ、プッシュしてみてください。それがうまくいけば、

それは私のために働いた。最近のコミットが破損している可能性が最も高いので、これはかなり一般的なシナリオだと思いますが、さらに1つ失うと、おそらくこのような方法を使用できgit cherrypick、とreflog を慎重に使用できますの中で.git/logs/HEAD。

この問題が発生したとき、私は最近の変更をバックアップし（変更内容を知っていたので）、そのファイルを削除しました。次に、git pullを実行しました。ただし、注意してください。これは機能しない場合があります。

システムがクラッシュした後、これに遭遇しました。私がしたことはこれです：

（破損したコミットは失われますが、変更は保持されます。この手順の最後にこれらのコミットを再作成する必要がある場合があります）

• コードをバックアップします。
• 作業ディレクトリに移動し、.gitフォルダーを削除します。
• 次に、リモートを別の場所に複製し、その中に.gitフォルダをコピーします。
• 作業ディレクトリに貼り付けます。
• 思い通りにコミットします。

.gitフォルダを削除して、もう一度追加します。この簡単な解決策は私にとってうまくいきました。