Recuperando arquivo adicionado depois de fazer o git reset –hard HEAD ^

Eu adicionei um novo arquivo F1 e fiz alterações em outro arquivo F2, mas depois fiz um “git reset –hard HEAD ^” e perdi todas as alterações nos arquivos.

Existe alguma maneira, eu posso recuperá-los.

Eu olhei para uma questão relacionada aqui: Como eu posso desfazer o git reset –hard HEAD ~ 1? mas, essa questão assume que a pessoa fez um commit do git.

Você pode (com algum trabalho) recuperar o estado do arquivo no último “git add “. Você pode usar

$ git fsck --cache --no-reflogs --lost-found --unreachable HEAD 

e, em seguida, examine os arquivos no diretório ‘.git / lost-found / other’.

Por favor, leia git fsck manpage.

(Estou supondo que o arquivo ausente não faz parte de nenhum commit. Caso contrário, git log --all -g --diff-filter=D --stat é seu amigo.)

  1. Obter lista de arquivos inacessíveis que git conhece um nome de arquivo:

     git fsck --unreachable --no-reflogs --no-cache HEAD | fgrep " tree " \ | cut -d " " -f3 | xargs -r -n1 git ls-tree \ | fgrep " blob " | cut -d " " -f 3- | sort -k2 -u 
  2. Se você vir algo interessante, git cat-file blob SHA-1-of-interesting-file irá gerar o arquivo para a saída padrão. (Exemplo: git cat-file blob b8f0bdf56 > recovered-logo.png )

Infelizmente, se o arquivo que está faltando não fizer parte de nenhum commit, o git não possui timestamp e, como tal, não é possível imprimir várias versões de arquivos ordenados por horário.

Se o arquivo que faltava nunca foi preparado ( git stage ou git add ) ou stashed ( git stash ), você está completamente sem sorte, porque, até onde git sabe, o arquivo nunca existiu. (Você ainda pode tentar fazer um git fsck --no-reflogs --lost-found e olhar em volta no diretório .git/lost-found/other para ver se você tem alguma coisa que valha a pena guardar no caso de o git realmente ter uma cópia do seu desaparecido arquivo por algum acidente sorte. Você não tem nomes de arquivo para ajudá-lo neste caso, apenas o conteúdo do arquivo.)

Caso você tenha perdido alguns commits (ao invés de apenas arquivos), você provavelmente vai querer rodar algo assim:

 gitk --all $( git fsck | awk '/dangling commit/ {print $3}'; git log -g --pretty='format:%H' ) 

Isso irá rodar o gitk com todos os branches, todo o reflog e todos os commits pendentes. Você pode querer adicionar -n 10000 ou algum outro limite caso seu repository tenha muitos commits (digamos, kernel linux). Se você não tem o gitk , você pode executar uma versão menor usando apenas a linha de comando como esta:

 git log --all --decorate --stat --graph --date-order $( git fsck | awk '/dangling commit/ {print $3}'; git log -g --pretty='format:%H' ) 

ou uma versão com saída menos detalhada

 git log --all --decorate --oneline --graph --date-order $( git fsck | awk '/dangling commit/ {print $3}'; git log -g --pretty='format:%H' ) 

Existe um git plugin que faz isso fora da checkbox:

https://github.com/pendashteh/git-recover-index

 $ cd /path/to/disatered/repo $ git clone git@github.com:pendashteh/git-recover-index.git $HOME/.git-recover-index $ $HOME/.git-recover-index/git-recover-index.sh 

Na verdade, se você adicionou o object ao índice (usando git add), há um blob criado para esse estado do object – mas não há um object tree (e, portanto, commit) que esteja se referindo a ele. É assim que se obtém um arquivo de object solto “pendente” e, se você executar o git fsck, ele mostrará o blob não referenciado (o git gc excluirá esses tipos de objects se forem executados).

Por causa disso, você pode usar o reflog, se tiver habilitado, para tentar restaurar o estado do índice para o arquivo F1 que foi adicionado. Se você não adicionou F2, então, como Greg disse, git não sabe nada sobre isso e você está sem sorte.

Experimente este http://gitready.com/advanced/2009/01/17/restoring-lost-commits.html

Eu tive um ataque cardíaco pelas mudanças que perdi. Mas depois de seguir este post. Eu tenho minhas alterações de volta