Git corruption master branch

9

J'ouvre mon référentiel Git à l'aide de gitExtensions sur Windows 7 pour un projet Visual Studio. Il est soudainement vide. Le référentiel existe, mais tous mes commits ont disparu.

J'utilise l'interface graphique et je crois que c'est la première fois que je l'ouvre depuis qu'ils l'ont mise à jour.

Je ne sais pas quoi faire pour récupérer mes engagements.

Quand je tape

git log

je reçois

fatal: mauvaise révision par défaut 'HEAD'

Mise à jour
Après avoir consulté /programming/1545407/recovering-broken-git-repository j'ai essayé

git fsck

il est revenu:

erreur: invalide HEAD
fatal: l'objet lâche 36b7d9e1ca496bcb864c0b9c8671fcec97fbda31 (stocké dans .git / obj ects / 36 / b7d9e1ca496bcb864c0b9c8671fcec97fbda31) est corrompu

Validation des retours:

erreur: impossible de résoudre la référence HEAD: aucun fichier ou répertoire de ce type n'est
fatal: impossible de verrouiller la référence HEAD

et journalisation des retours de branche principale

$ git log master warning: ignorer les références / têtes / maître de référence cassées. avertissement: ignorer les références / têtes / maître de référence cassées. fatal: argument ambigu 'master': révision inconnue ou chemin d'accès absent de l'arborescence de travail. Utilisez '-' pour séparer les chemins des révisions

Je vais juste continuer à coller des choses qui pourraient être pertinentes

$ git reflog master
warning: ignorer les références / têtes / maître de référence cassées.
avertissement: ignorer les références / têtes / maître de référence cassées.
fatal: argument ambigu 'master': révision inconnue ou chemin d'accès absent de l'arborescence de travail.
Utilisez '-' pour séparer les chemins des révisions

Plus d'informations éventuellement utiles: chaque fois que je supprime le fichier corrompu, un autre prend sa place. Je commence à penser que c'est quelque chose à voir avec la branche principale pointant vers la mauvaise chose ou quelque chose. parce que je suppose que la tête pointe vers le maître.

Un jour plus tard:
j'ai donc mis mon compagnon là-dessus, il a pu parcourir les journaux et il a dit que les hachages dans les journaux ne correspondaient pas aux objets du dossier. Il a essayé de réinitialiser la branche principale aux journaux ou quelque chose comme ça, je me suis un peu perdu. J'espère que c'est utile

— MrJD
source

liés à SO: stackoverflow.com/questions/6214711/… stackoverflow.com/questions/1545407/…

— Heavyd

1

@heavyd veuillez vérifier la mise à jour

— MrJD

3

Le référentiel existe, mais tous mes commits ont disparu.

Que veux-tu dire exactement? L'arbre de travail est-il toujours là? .git/Existe- t- il? Y a-t-il des fichiers dedans?

Les messages que vous avez publiés suggèrent que le fichier .git/HEADn'existe pas. Il définit l'état attendu de l'arborescence de travail (ce que vous aviez extrait). Si ce fichier a disparu, git ne sait pas où vous étiez.

Vous pouvez essayer de créer le fichier vous-même, avec ce contenu: ref: refs/heads/master

Si vous étiez sur une branche différente, remplacez simplement "master" par le nom de la branche. Si vous n'étiez pas sur une succursale, ce serait plus compliqué.

.git/logs/HEADenregistre les états passés de HEAD, avec les lignes suivantes en bas. Cet exemple de ligne montre une extraction: 25f2a6099fb5f9f2192a510c42f704f9fc4bcecb 65abb1a3dc102e2498860f01fb179cda4c51decb Rainer Blome <rainer.blome@wherever.you.are.com> 1346938344 +0200 checkout: moving from master to MySuperBranch

Les SHA1 en face font référence à des commits. Vous devriez pouvoir les trouver dans le journal de branche, par exemple .git/logs/refs/heads/master.

La sortie git reflog que vous avez donnée refs/heads/mastermanque également. Son seul contenu est censé être le SHA1 du dernier commit sur celui-ci (et une nouvelle ligne). Vous pouvez trouver le dernier SHA1 à la fin du journal de branche, par exemple .git/logs/refs/heads/master.

— Rainer Blome
source

2

Si .git / HEAD existe et que son contenu est ref: refs/heads/masteralors vérifie le fichier refs / heads / master il doit contenir le sha1 du dernier commit.

Si ce fichier était corrompu et plein de caractères NULL Modifiez ce fichier et mettez le sha1 du dernier commit de .git/logs/HEADou celui avant le dernier commit.

Alors fais git reset --hard 'sha1 of the commit that you selected'

— zaki
source

il était en effet plein de caractères NULL donc j'ai mis dans le sha1 du commit précédent, mais faire la réinitialisation de git a entraîné "erreur: update_ref a échoué pour la ref 'HEAD': ne peut pas verrouiller ref 'HEAD': impossible de résoudre la référence HEAD: Argument invalide "

— Fantabolous

1

Il semble que votre dépôt ait été corrompu. La chose la plus simple à faire serait de récupérer votre dépôt à partir d'une sauvegarde ou de recloner le dépôt à partir de la source d'origine (en supposant que vous n'aviez pas des tonnes de travail dans le dépôt).

Si le resotring / clonage n'est pas une option, je recommanderais de lire Pro Git (livre en ligne gratuit ou version papier ). L'ensemble du livre est très informatif, mais surtout jetez un œil au dernier chapitre pour comprendre comment Git fonctionne en interne. Une fois que vous avez compris le fonctionnement de Git, consultez les instructions de Linus sur la récupération d'objets corrompus .

— lourd
source

Donc, malheureusement, je ne sauvegardais pas les fichiers cachés, .git était caché. Je n'ai pas vraiment assez de temps pour lire un livre entier, y a-t-il quelque chose que vous pensez que je pourrais essayer?

— MrJD

«Lire un livre sur les éléments internes» peut être un bon conseil général, mais il n'aide pas à résoudre le problème et la question spécifiques.

— Burhan Ali

0

Après avoir navigué sur le Web pendant un certain temps, j'ai finalement trouvé cela et cela a fonctionné.

git fetch origin
git reset --hard origin/master

— Leye Odumuyiwa
source

Cela obtient tous les changements origin(si tout va bien pas trop de travail effectué localement), puis force la masterbranche locale à se mettre d'accord avec la télécommande. Attention, --resetsignifie éliminer tous les changements locaux! De plus, s'il n'était pas trop cassé, il git reset origin/masteraurait juste restauré le dernier état connu (enregistré) de la masterbranche.

— vonbrand