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 ‘force push’ sur le commit.
Le dépôt local est obsolète.
Il se peut que votre dépôt local n’ait pas encore le commit. 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é.
Conseil
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 le commit ou a effectué un envoi (push) forcé sur la branche, le commit manquant est peut-être devenu orphelin (de sorte qu’il est inaccessible à partir d’une référence) et ne sera donc pas intégré 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. 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.
Supposons que la personne ait toujours une branche locale (appelons-la B) contenant le commit. 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. 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 court.
$ 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 push forcés
Évitez le push forcé vers un dépôt, sauf si absolument nécessaire. C’est particulièrement vrai si plusieurs personnes peuvent effectuer un envoi (push) au dépôt. Si quelqu’un effectue un push forcé vers un dépôt, ce push peut écraser des commits sur lesquels d’autres personnes ont basé leur travail. Un push forcé modifie l’historique du dépôt et peut corrompre les pull requests.
Lectures complémentaires
- « Utilisation de dépôts distants » du livre Pro Git
- « Récupération de données » dans le livre Git Pro