커밋하기 전에 새로운 레포의 전체 디렉토리에 git rm -r -f을 작성했습니다. 나는 가지가 없었다.첫 번째 커밋 이전에 git rm -r f (모호한 인수 'HEAD')를 실행하십시오.
스택 오버플로에 대한 해답을 시도했지만 도움이되지 않았습니다. 나는이 시도 :
git reset --hard HEAD
을하지만이있어 :
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
내가 파일을 다시 얻을 수있는 방법이 있나요를?
커밋을 만들기 전에 데이터를 삭제 했으므로 데이터가 손실됩니다.
git reset --hard은 다시 초기화 할 커밋이 없기 때문에 작동하지 않습니다. 따라서 '모호한 인수'오류는 자식이 없기 때문에 당신이 참조하고있는 커밋을 파악할 수 없습니다.
사실, 수 있습니다 회수 파일.
git rm -r은 색인에있는 파일 만 제거하므로 항목을 제거하려면 이미 git add -ed가 있어야합니다. 그렇게했을 때, git은 blob-contents의 SHA-1 "실제 이름"을 사용하여 각 파일의 내용 사본을 저장소에 저장합니다.
이제 git fsck --lost-found을 실행하면 git은 참조가없는 객체 (즉, 저장소의 모든 객체)를 찾고 dangling <type> <SHA-1>을 인쇄합니다. 각 "덩어리"에 대한 (이 경우, 발견 한 모든) 그것은 SHA-1 이름 .git/lost-found/other/에 내용을 기록 :
$ git rm -r -f .
rm 'bar'
$ git fsck --lost-found
notice: HEAD points to an unborn branch (master)
Checking object directories: 100% (256/256), done.
notice: No default references
dangling blob f53433f357a56ddb698196519f30eb390ae684cb
$ cat .git/lost-found/other/f53433f357a56ddb698196519f30eb390ae684cb
this is file bar
$
이것은 또한 일부 커밋을 할 저장소 작동하고 일반적이다 "참조가 있었지만 더 이상 사용하지 않는 물건을 복구"하는 방법. 이렇게하면 git add 파일을 찾은 다음 이전 "이전"내용의 새로운 내용으로 바꿔 git commit ing 앞에 넣습니다. 또한 버려진 git 숨김을 포함하여 "포기 된"커밋을 찾습니다. (커밋은 .git/lost-found/commit/입니다.)
위의 예에서 파일 bar은 편리하게 파일 내용이 bar 인 것으로 주장합니다. 대부분의 실제 사례에서 복구 된 얼룩을보고 원래 이름으로 추측해야합니다.
그래서, 그게 뭐죠? 망했다. – user3393589
짧은 대답 : 예. 이렇게하면 백업 복사본을 만드는 것이 중요하다는 것을 알 수 있습니다. 이 데이터가 정말로 필요하다면 Photorec와 같은 데이터 조각 툴에 약간의 행운이있을 것입니다. –