Git: "손상된 느슨한 개체"

Git: "손상된 느슨한 개체"

리모컨에서 풀할 때마다 압축에 대한 다음 오류가 발생합니다.수동 압축을 실행하면 다음과 같이 표시됩니다.

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

그걸 어떻게 해야 할지 아는 사람?

cat-file에서 얻은 정보는 다음과 같습니다.

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

그리고 gitfsck에서 저는 다음과 같은 것을 얻습니다(실제로 관련이 있는지는 모르겠습니다).

$ 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

누가 이걸 해독하는 것을 도와줄 수 있나요?

저도 같은 문제가 있었습니다.

이 수정 프로그램을 사용하려면 리포지토리의 손상되지 않은 원격 복사본에 액세스해야 하며 로컬에서 작업하는 복사본은 그대로 유지됩니다.

하지만 몇 가지 단점이 있습니다.

• 푸시되지 않은 커밋의 레코드가 손실되므로 커밋을 다시 실행해야 합니다.
• 당신은 모든 스테이시를 잃게 될 것입니다.

픽스

repo 위의 상위 디렉터리에서 다음 명령을 실행합니다('foo'를 프로젝트 폴더 이름으로 대체).

1. 손상된 디렉터리의 백업을 만듭니다.
   cp -R foo foo-backup
2. 원격 저장소의 새 복제본을 새 디렉터리로 만듭니다.
   git clone git@www.mydomain.de:foo foo-newclone
3. 디렉터리를 삭제합니다.
   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 is 빈 오류: 개체 파일 .git/objects/ce/theRef is 빈 치명적: looseobjects theRef(.git/objects/ce/theRef에 저장됨)가 손상되었습니다.

작업 손실 없이 2개의 명령만 사용하여 다시 작업할 수 있었습니다(수정된 파일/커밋되지 않은 변경 사항).

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

그 후에 나는 달렸습니다.git status레포는 괜찮았고 변경 사항이 있었습니다(커밋되어야 합니다, 지금 수행하십시오...).

git 버전 1.9.1

이 솔루션이 작동하지 않고 보다 급진적인 접근 방식이 필요할 경우를 대비하여 기억하는 모든 변경 사항을 백업해야 합니다.

트리 개체가 손상된 것 같습니다.다른 사람에게서 해당 개체를 가져와야 합니다.그들이 손상되지 않은 버전을 가지고 있기를 바랍니다.

어떤 파일이 있어야 하는지 추측하여 다른 사람의 유효한 버전을 찾을 수 없는 경우 실제로 재구성할 수 있습니다.개체의 날짜와 시간이 일치하는지 확인할 수 있습니다.그것들은 관련된 블롭일 수 있습니다당신은 그 물체들로부터 나무 물체의 구조를 추론할 수 있습니다.

스콧 채콘의 깃 내부와 관련된 깃 스크린캐스트를 살펴보십시오.이것은 후드 아래에서 깃이 어떻게 작동하는지, 그리고 만약 당신이 정말 갇혀 있고 다른 사람으로부터 그 물체를 얻을 수 없다면 이 탐정 일을 어떻게 해야 하는지를 보여줄 것입니다.

커밋 메시지를 쓰는 동안 컴퓨터가 충돌했습니다.재부팅한 후 작업 트리가 그대로 유지되어 변경 사항을 성공적으로 커밋할 수 있었습니다.

, 제가 하만지를 뛰려고 때, 내도망고했을때려치가때했▁however을,고려▁i▁when▁to,만.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 해시 표현입니다.의 해시된 버전을 가져야 한다고 합니다.some/file.whatever에장된에 저장되어 ..git/object/xx/12345그리고 오류를 수정하는 것은 대부분 "잘못된 객체"가 어떤 파일을 나타내야 하는지 파악하는 문제인 것으로 밝혀졌습니다.

세부 사항

가능한 옵션은 다음과 같습니다.

1. 빈 파일 삭제
2. 파일을 Git가 허용할 수 있는 상태로 가져옵니다.

접근 1: 객체 파일 제거

제가 가장 먼저 시도한 것은 객체 파일을 옮기는 것이었습니다.

mv .git/objects/xx/12345 ..

그것은 효과가 없었습니다. Git은 끊어진 링크에 대해 불평하기 시작했습니다.접근 2.

접근 2: 파일 수정

리누스 토르발스는 문제를 해결한 객체 파일을 복구하는 방법에 대해 잘 알고 있습니다.주요 단계는 여기에 요약되어 있습니다.

$> # 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 gc --aggressive --prune=now

완료하는 데 시간이 좀 걸리지만 모든 느슨한 개체 및/또는 손상된 인덱스가 수정되었습니다.

해라

git stash

이것은 저에게 효과가 있었습니다.그것은 당신이 저지르지 않은 모든 것을 숨기고 문제를 해결합니다.

단순 운영git prune나를 위해 이 문제를 해결했습니다.

시스템이 다운된 후에 이런 상황이 발생했습니다.제가 한 일은 다음과 같습니다.

손상된 커밋은 손실되지만 변경 사항은 유지됩니다.이 절차가 끝나면 이러한 커밋을 다시 생성해야 할 수도 있습니다.

• 코드를 백업합니다.
• 의 작업 하여 작업디리삭제다니합여이동하로렉토를 합니다..git폴더를 누릅니다.
• 다른 하고 이제원위에복복사다니합고를 합니다..git폴더가 들어 있습니다.
• 작업 디렉토리에 붙여넣습니다.
• 당신이 원하는 대로 하세요.

저는 방금 이것을 경험했습니다. Gitrepo에 글을 쓰는 동안 제 기계가 고장이 나서 손상되었습니다.저는 다음과 같이 고쳤습니다.

원격 레포에 푸시하지 않은 커밋의 수를 확인하는 것으로 시작했습니다.

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 log 는또.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

한 후 합니다.", 손된파일제거교파즉체합다니일로정상하상고을▁i▁and,다니즉교합체▁file일▁corrupted.이 작업을 여러 번 수행해야 할 수도 있습니다.마침내 당신이 달릴 수 있는 지점이 있을 것입니다.fsck차오없이▁ commit"이 있을입니다. 이 및 보서에 "dangling commit" 및 "dangling blob" 이시될표수행있습니다고수있습니다"될시dang표b▁"". 이는 이 폴더의 기본값 및 수정 결과이며 정상입니다.쓰레기 수거업자는 적절한 시기에 그것들을 제거할 것입니다.

따라서 (적어도 내 경우에는) 손상된 트리가 푸시되지 않은 커밋이 손실되는 것을 의미하지 않습니다.

물건들이 부패했을 때 내가 있던 지점의 이름과 함께 그 대답에 대한 스테판의 언급 외에 펠리페 페레이라(위)가 제공한 해결책이 나에게 효과가 있었습니다.

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

리눅스 민트 크래시 후에도 동일한 문제가 발생하고 노트북을 종료하기 위해 전원 버튼을 누르면 .git가 손상됩니다.

find .git/objects/ -empty -delete

그 후 오류 치명적인 오류가 발생합니다. 불량 객체 헤드입니다.방금 내 깃을 다시 초기화했습니다.

git init

원격 repo에서 가져오기

git fetch

Git을 확인하려면 다음을 사용합니다.

git status

그리고 다시 일입니다.로컬 변경사항을 잃지 않으므로 코드를 다시 작성하지 않고 커밋할 수 있습니다.

사용자 1055643의 응답에 마지막 단계가 없습니다.

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 stash; git stash pop나의 문제를 고쳤습니다.

저는 여기서 다른 많은 단계를 따랐습니다. 리누스의 git tree/objects를 보고 누락된 것을 찾는 방법에 대한 설명은 특히 도움이 되었습니다. git-git blob 복구

하지만 결국 부분적인 디스크 장애로 인해 트리 개체가 느슨하거나 손상되었으며 트리 개체는 쉽게 복구되거나 해당 문서에 포함되지 않았습니다.

결국, 나는 충돌하는 것을 옮겼습니다.objects/<ha>/<hash>가 되지 사되지않는용을 했습니다.git unpack-objects상당히 최신 클론의 팩 파일을 사용합니다.그것은 사라진 나무 물체를 복원할 수 있었습니다.

이전에 보관된 자료를 풀면 부작용이 발생할 수 있으며 여기에 있는 다른 질문에서 다루었습니다.

불량 객체 오류도 발생했습니다.

./objects/x/x

손상된 개체의 디렉터리에 들어가서 성공적으로 수정했습니다.해당 개체에 할당된 사용자가 내 git 사용자의 사용자가 아닌 것을 확인했습니다.어떻게 된 일인지는 모르겠지만, 저는 도망쳤습니다.chown git: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웹 인터페이스 또는 두 번째 클론을 통해 기록을 확인할 수 있습니다.

는 번두클서저는에론을 .git log -n 2 c2388의전을밝다의 c2388그런 다음 수동으로 수정했습니다..git/refs/heads/master그리고..git/refs/remotes/origin/master의 전신이 c2388에 c2388그러면 제가 할 수 있는 것은git fetch.git fetch빈 개체에서 충돌이 발생하여 몇 번 실패했습니다.나는 이 빈 물건들을 각각 제거했습니다.git fetch ▁has▁the. 그것이 치유했습니다.그것이 저장소를 치유했습니다.

방금 사건을 맡았습니다문제는 정상적인 사용자 대신 손상된 파일의 소유권이 루트라는 것이었습니다.이것은 다른 사용자가 "sudosu --"를 수행한 후 서버에서 수행된 커밋으로 인해 발생했습니다.

먼저 다음을 사용하여 손상된 파일을 식별합니다.

$> 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/objects/에서 개체를 찾을 수 없는 경우 공간을 절약하기 위해 [packed][packed]되었을 수 있습니다.)

이것은 Dropbox 또는 Dropbox에서 폴더를 연결하는 것과 관련된 문제인 것 같습니다.아마도 다른 유사한 서비스도 마찬가지일 것입니다.가 내가갔때에 갈 때.git push개체 손상 오류가 발생합니다.저에게, macOS Big Sur에서, 수정은 단순히 레포의 재귀적인 복사본을 Dropbox 외부의 디렉토리로 만드는 것이었습니다.이것이 Dropbox가 손상된 동적 참조를 위한 라이브 파일을 끌어오는 원인이 되었다고 생각합니다.복사한 후에 저는 즉시 할 수 있었습니다.git push틀림 없이

저는 이전에도 같은 문제가 있었습니다.나는 단지 객체 파일을 제거함으로써 그것을 통과합니다..git/objects디렉토리입니다.

아래의 이 오류에 대해.

$ 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

솔루션:

1. .gitfolder

• 창에서 다음 명령을 실행하여 이 작업을 수행할 수 있습니다.cmd: attrib +s +h .git

2. 그런 다음 .git/objects 폴더로 이동합니다.

3. (에 .git/objects/45/ba4ceb93bc812ef20a6630bb27e9e0b33a012a) is corrupted당신은 그 물체가 "45"라는 감독에게서 발견되는 것을 볼 수 있습니다.따라서 디렉토리로 이동합니다..git/objects/45/

4. 마지막으로 ba4ceb93bc812ef20a6630bb27e9e0b33a012a라는 개체를 찾아서 삭제합니다.

, 당은다같확수있다습니인할로 확인할 수.git status또는git add .변경하고 계속 진행합니다.

저도 똑같은 문제가 있었습니다. 제가벼운 리모콘 Git repo에서 말이죠.많은 문제를 해결한 후, 저는 동료 중 한 명이 .git/objects의 일부 파일에 444(r--r---)가 아닌 440(r---)의 권한을 갖는 커밋을 했다는 것을 알게 되었습니다.bare git repo 안에 있는 "chmod 444-R objects"로 사용 권한을 변경해달라고 동료에게 요청한 후 문제가 해결되었습니다.

저는 그냥 이런 문제가 있었어요.가장 최근의 커밋(및 마스터 브랜치)을 손상시킨 시스템 충돌로 인해 특정 문제가 발생했습니다.저는 밀어붙이지 않았고, 그 약속을 다시 하고 싶었습니다.저의 경우, 저는 다음과 같이 대처할 수 있었습니다.

1. 만의 백업 .git/:rsync -a .git/ git-bak/
2. 인확을 합니다..git/logs/HEAD유효한 커밋 ID를 가진 마지막 줄을 찾습니다.저에게 이것은 두 번째로 최근의 약속이었습니다.작업 디렉터리 버전의 파일을 가지고 있었기 때문에 좋았습니다. 원하는 모든 버전을 가지고 있었습니다.
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. 모든 것이 좋아 보이면 밀어보세요.그게 효과가 있다면,

그것은 저에게 효과가 있었습니다.만, 한만 더할 수 것입니다. 하지만 만약 당신이 하나를 더 잃는다면, 당신은 여전히 이러한 방법을 사용할 수 있을 것이고, 신중하게 사용할 수 있을 것입니다.git cherrypick in 고리인그로그..git/logs/HEAD.

이 문제가 발생했을 때 최근 변경 사항을 백업한 후 .git/location에서 불만을 제기하는 파일을 삭제했습니다.그 다음에 저는 당기기를 했습니다.그래도 몸조심하세요, 이것은 당신에게 효과가 없을 수도 있습니다.

백업을 생성하고 리포지토리를 새 디렉터리로 복제합니다.

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 Checkout에서 버전이 다른 다양한 Git 클라이언트를 사용할 때 발생합니다.생각해 보십시오.

• 명령줄
• IDE 빌드 it
• 도커/VM 컨테이너 내부
• GIT GUI 도구

커밋을 만든 동일한 클라이언트로 푸시해야 합니다.

내가 다른 밀지 않은 가지를 잃어버리지 않기 위해 한 것: 부서진 물체에 대한 참조는 다음에 있어야 합니다.refs/heads/<current_branch>에 ..git\logs\refs\heads\<current_branch>마지막 커밋의 값이 정확히 같다는 것을 알 수 있습니다.이전 커밋의 파일을 첫 번째 파일로 복사했는데 문제가 해결되었습니다.

Windows(윈도우) 컴퓨터가 자동으로 재부팅되기로 결정한 후 이 오류가 발생했습니다.

다행히도 원격 저장소가 최신 상태여서 새로 Git 클론을 만들었습니다.

Windows 10 컴퓨터에서 Git 저장소가 있는 문서 폴더를 드라이브 하나가 백업하는 경우에도 비슷한 문제가 있었습니다.

git 객체 디렉터리에서 객체를 보니 녹색 체크 표시가 아니라 해당 파일의 파란색 동기화 아이콘이 보입니다.다른 모든 개체 파일에 녹색 체크 표시가 있습니다.장난을 치고, 여러 가지를 시도하면서 이 장치에 항상 이 폴더를 유지하는 옵션을 선택하려고 했지만 오류 0x80071129가 발생했습니다. 오류 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를 관리자로 실행할 것을 제안합니다(컴퓨터를 재부팅해야 함).저는 그것을 했고 그것은 제 문제를 해결했습니다.

저도 똑같은 오류가 발생하여 변경 사항을 잃지 않고 레포를 되찾을 수 있었습니다.

부패 이유가 여러 가지가 될 수 있기 때문에 다른 사람들에게 효과가 있을지는 모르겠지만 시도해 볼 가치가 있습니다.

I:

• 만약을 위해 손상된 Git 저장소의 백업을 여러 번 수행했습니다.
• 원격 저장소에서 지속적으로 푸시된 버전 복제
• HEAD, FETCH_HEAD, ORG_HEAD 등과 관련된 모든 파일을 제외한 모든 파일을 손상된 .git 폴더에서 복사했습니다.가장 중요한 것은 ref, obj, 그리고 인덱스입니다.
• 유효한 내역이지만 손상된 인덱스로 종료되었습니다. 이 게시물의 솔루션을 적용했습니다. Git를 사용할 때 "오류: 불량 인덱스 – 치명적: 인덱스 파일 손상"을 해결하는 방법

그리고 제 저장소는 다시 작동했습니다...

잘못된 내용을 적용하지 않도록 원격에서 다시 복제하고 복원된 리포지토리에서 저장할 변경 사항을 체크아웃한 후 새로 커밋했습니다.

언급URL : https://stackoverflow.com/questions/4254389/git-corrupt-loose-object