Ramificação mestre corrompida do Git

9

Abro meu repositório Git usando gitExtensions no Windows 7 para um projeto do Visual Studio. De repente está vazio. O repositório existe, mas todos os meus commits desapareceram.

Estou usando a interface gráfica e acredito que seja a primeira vez que a abri desde que a atualizou.

Não sei o que fazer para recuperar meus commits.

Quando digito

git log

eu recebi

fatal: revisão padrão incorreta 'HEAD'

Atualização
Depois de olhar para /programming/1545407/recovering-broken-git-repository, tentei

git fsck

retornou:

erro:
fatal HEAD inválido : o objeto solto 36b7d9e1ca496bcb864c0b9c8671fcec97fbda31 (armazenado em .git / obj ects / 36 / b7d9e1ca496bcb864c0b9c8671fcec97fbda31) está corrompido

Confirmar retornos:

erro: incapaz de resolver a referência HEAD: Nenhum arquivo ou diretório
fatal: não é possível bloquear HEAD ref

e registrando devoluções de ramificações principais

$ git log master warning: ignorando ref refs / heads / master quebrados. aviso: ignorando ref refs / heads / master quebrados. fatal: argumento ambíguo 'mestre': revisão desconhecida ou caminho que não está na árvore de trabalho. Use '-' para separar caminhos das revisões

Vou continuar colando coisas que podem ser relevantes

Aviso principal do $ git reflog
: ignorando ref refs / heads / master quebrados.
aviso: ignorando ref refs / heads / master quebrados.
fatal: argumento ambíguo 'mestre': revisão desconhecida ou caminho que não está na árvore de trabalho.
Use '-' para separar caminhos das revisões

Informações possivelmente mais úteis: toda vez que eu apago o arquivo corrompido, outro ocorre. Estou começando a pensar que é algo a ver com o ramo principal apontando para a coisa errada ou algo assim. porque eu assumo que a cabeça está apontando para o mestre.

Um dia depois:
então eu coloquei meu companheiro nisso, ele foi capaz de examinar os logs e disse que os hashes nos logs não correspondem aos objetos da pasta. Ele tentou redefinir a ramificação principal para os logs ou algo assim, fiquei um pouco perdido. Espero que seja útil

— MrJD
fonte

relacionado no SO: stackoverflow.com/questions/6214711/… stackoverflow.com/questions/1545407/…

— heavyd 9/12

11

@heavyd verifique a atualização

— MrJD 9/12

3

O repositório existe, mas todos os meus commits desapareceram.

O que exatamente você quer dizer? A árvore de trabalho ainda está lá? Existe .git/? Existem arquivos nele?

As mensagens que você postou sugerem que o arquivo .git/HEADnão existe. Ele define o estado esperado da árvore de trabalho (o que você fez check-out). Se esse arquivo desapareceu, o git não sabe onde você estava.

Você pode tentar criar o arquivo você mesmo, com este conteúdo: ref: refs/heads/master

Se você estava em uma ramificação diferente, substitua "master" pelo nome da ramificação. Se você não estivesse em um galho, seria mais complicado.

.git/logs/HEADregistra estados passados de HEAD, com linhas posteriores na parte inferior. Esta linha de exemplo mostra um checkout: 25f2a6099fb5f9f2192a510c42f704f9fc4bcecb 65abb1a3dc102e2498860f01fb179cda4c51decb Rainer Blome <rainer.blome@wherever.you.are.com> 1346938344 +0200 checkout: moving from master to MySuperBranch

Os SHA1s na frente referem-se a confirmações. Você deve encontrá-los no log de ramificação, por exemplo .git/logs/refs/heads/master.

Também refs/heads/masterestá faltando a saída do git reflog que você forneceu . Seu único conteúdo deve ser o SHA1 da confirmação mais recente (e uma nova linha). Você pode encontrar o SHA1 mais recente no final do log da filial, por exemplo .git/logs/refs/heads/master.

— Rainer Blome
fonte

2

Se .git / HEAD existe e seu conteúdo é ref: refs/heads/masterverificado no arquivo refs / heads / master, ele deve conter o sha1 da última confirmação.

Se esse arquivo estiver corrompido e cheio de caracteres NULL Edite esse arquivo e coloque o sha1 da confirmação mais recente .git/logs/HEADou a anterior à última confirmação.

Então faça git reset --hard 'sha1 of the commit that you selected'

— zaki
fonte

ele estava cheio de caracteres NULL, então coloquei o sha1 do commit anterior, mas a redefinição do git resultou em "error: update_ref falhou para ref 'HEAD': não é possível bloquear ref 'HEAD': não é possível resolver a referência HEAD: argumento inválido "

— fantabolous 14/12

1

Parece que seu repositório foi corrompido. A coisa mais fácil a fazer seria recuperar seu repositório de um backup ou cloná-lo novamente da fonte original (supondo que você não tenha muito trabalho no repositório).

Se a redefinição / clonagem não for uma opção, eu recomendaria a leitura no Pro Git (livro on-line gratuito ou versão em papel ). O livro inteiro é muito informativo, mas especialmente dê uma olhada no último capítulo para entender como o Git funciona internamente. Depois de entender como o Git funciona, consulte as instruções de Linus sobre a recuperação de objetos corrompidos .

— pesado
fonte

Então, infelizmente, eu não estava fazendo backup de arquivos ocultos, o .git estava oculto. Eu realmente não tenho tempo suficiente para ler um livro inteiro, há algo que você acha que eu poderia tentar?

— MrJD

"Ler um livro sobre os internos" pode ser um bom conselho geral, mas não ajuda a resolver o problema específico e a questão em questão.

— 22912 Burhan Ali

0

Depois de navegar na web por um tempo, finalmente encontrei isso e funcionou.

git fetch origin
git reset --hard origin/master

— Leye Odumuyiwa
fonte

Isso obtém qualquer alteração origin(espero que não seja muito trabalho feito localmente) e força a masterfilial local a concordar com o controle remoto. Cuidado, --resetmeios descartar quaisquer alterações locais! Além disso, se não estivesse muito quebrado, apenas git reset origin/masterteria restaurado o último estado conhecido (registrado) da masterramificação.

— vonbrand 20/02