Lorsque vous utilisez git show pour afficher une validation spécifique sur la ligne de commande, il se peut que vous obteniez une erreur irrécupérable.
Par exemple, vous pouvez recevoir une erreur bad object localement :
$ git show 1095ff3d0153115e75b7bca2c09e5136845b5592
> fatal: bad object 1095ff3d0153115e75b7bca2c09e5136845b5592
En revanche, lorsque vous affichez la validation sur GitHub.com, vous pouvez la voir sans aucun problème :
github.com/ACCOUNT/REPOSITORY/commit/1095ff3d0153115e75b7bca2c09e5136845b5592
Il existe plusieurs explications possibles :
- Le dépôt local est obsolète.
- La branche contenant la validation a été supprimée, de sorte que la validation n’est plus référencée.
- Quelqu’un a effectué un envoi (push) forcé sur la validation.
Le dépôt local est obsolète.
Il se peut que votre dépôt local n’ait pas encore la validation. Pour obtenir des informations de votre dépôt distant dans votre clone local, utilisez git fetch :
git fetch REMOTE
Cela a pour effet de copier en toute sécurité les informations du dépôt distant vers votre clone local sans apporter de modifications aux fichiers que vous avez extraits. Vous pouvez utiliser git fetch upstream pour obtenir des informations d’un dépôt que vous avez dupliqué, ou git fetch origin pour obtenir des informations d’un dépôt que vous avez seulement cloné.
Astuce : pour plus d’informations, lisez la documentation sur la gestion des dépôts distants et l’extraction de données dans le livre Pro Git.
La branche qui contenait la validation a été supprimée
Si un collaborateur du dépôt a supprimé la branche contenant la validation ou a effectué un envoi (push) forcé sur la branche, la validation manquante est peut-être devenue orpheline (de sorte qu’elle est inaccessible à partir d’une référence) et ne sera donc pas extraite dans votre clone local.
Heureusement, si un collaborateur a un clone local du dépôt avec la validation manquante, il peut le renvoyer (push) à GitHub Enterprise Cloud. Il doit s’assurer que la validation est référencée par une branche locale, puis l’envoyer (push) en tant que nouvelle branche à GitHub Enterprise Cloud.
Supposons que la personne a toujours une branche locale (appelons-la B) contenant la validation. Il pourrait s’agir du suivi de la branche sur laquelle a été effectué un envoi (push) forcé ou qui a été supprimée, et qui n’a tout simplement pas encore été mise à jour. Pour conserver la validation, il peut envoyer (push) cette branche locale à une nouvelle branche (appelons-la recover-B) sur GitHub Enterprise Cloud. Pour cet exemple, supposons qu’il dispose d’un dépôt distant nommé upstream via lequel il a accès en envoi (push) à github.com/ACCOUNT/REPOSITORY.
L’autre personne exécute :
$ git branch recover-B B
# Create a new local branch referencing the commit
$ git push upstream B:recover-B
# Push local B to new upstream branch, creating new reference to commit
Maintenant, vous pouvez exécuter :
$ git fetch upstream recover-B
# Fetch commit into your local repository.
Éviter les envois (push) forcés
Éviter l’envoi (push) forcé à un dépôt, sauf absolue nécessité. C’est particulièrement vrai si plusieurs personnes peuvent effectuer un envoi (push) au dépôt. Si quelqu’un effectue un envoi (push) forcé à un dépôt, cet envoi peut remplacer des validations sur lesquelles d’autres personnes ont basé leur travail. Un envoi (push) forcé modifie l’historique du dépôt et peut endommager votre demande de tirage.
Pour aller plus loin
- « Utilisation de dépôts distants » dans le livre Pro Git
- « Récupération de données » dans le livre Git Pro