Comment puis-je me remettre d’un maître d’origine git push -f erroné?

Git ne jette généralement rien, mais se remettre de cela peut être difficile.

Si vous avez la bonne source, vous pouvez simplement la pousser dans la télécommande avec l’option --force . Git n’aura supprimé aucune twig sauf si vous le lui avez dit. Si vous avez effectivement perdu des commits, consultez ce guide utile pour récupérer les commits . Si vous connaissez le SHA-1 des commits que vous voulez, vous êtes probablement OK.

La meilleure chose à faire est de tout sauvegarder et de voir ce qui se trouve encore dans votre référentiel local. Faites de même sur la télécommande si possible. Utilisez git fsck pour voir si vous pouvez récupérer des choses, et surtout ne lancez pas git gc .

Avant tout, n’utilisez jamais l’option --force moins que vous ne le pensiez vraiment.

Si vous connaissez le hash de commit, c’est facile, recréez simplement votre twig.

 5794458...b459f069 master -> master (forced update) 

Supprimez la twig distante:

 git push origin :master 

recréez ensuite votre twig avec les commandes suivantes:

 git checkout 5794458 git branch master git push origin master 

La solution est déjà mentionnée ici

 # work on local master git checkout master # reset to the previous state of origin/master, as recorded by reflog git reset --hard origin/master@{1} # at this point verify that this is indeed the desired commit. # (if necessary, use git reflog to find the right one, and # git reset --hard to that one) # finally, push the master branch (and only the master branch) to the server git push -f origin master 

Si vous n’êtes pas sur ce repo local d’où vient la poussée forcée, au niveau de l’origine / du maître, il n’y a aucun moyen de récupérer. Mais si vous avez la chance d’utiliser GitHub ou GitHub for Enterprise , vous pouvez consulter l’API REST et récupérer le commit perdu en tant que correctif, par exemple:

1. Listez les événements et recherchez le format long commit sha1

https://api.github.com/repos/apache/logging-log4j2/events

2. Téléchargez le commit perdu et récupérez le correctif associé dans le chemin json .files [] / patch

https://api.github.com/repos/apache/logging-log4j2/commits/889232e28f3863d2a17392c06c1dd8cac68485de

3. Appliquer localement et repousser

git apply patch.patch && git commit -m “commit restauré” && git push maître d’origine

J’ai fait la même chose en défaisant une dernière poussée pour un seul fichier. Fini revenir à l’état d’origine du référentiel. J’utilisais les commandes git de Linus car j’avais la copie locale sous Linux. Heureusement, cette copie était toujours intacte.

Tout ce que j’ai fait a été (après avoir fait frénétiquement quelques copies du repository local):

 git add . git status 

(il a dit que l’origine / le master était en avance de 68 commits, très bien… c’était tous les commits que j’ai supprimés)

 git remote set-url origin  git push 

Et tout a été restauré tel qu’il était avant que je ne pousse avec force. La chose la plus importante à retenir est de ne jamais faire un check out. après avoir poussé avec force. Mais la meilleure pratique consiste à désactiver l’option Push. Je ne l’utilise plus jamais. J’ai appris ma leçon !!

Une autre façon de récupérer la validation perdue ou même de déterminer les validations perdues, si la poussée précédente n’est pas venue de votre repo local, est de regarder votre machine CI.

Si vous avez un travail qui teste la twig principale après chaque validation (ou série de validations consécutives), que vous devriez avoir, vous pouvez jeter un coup d’œil sur ce qu’il testait en dernier. C’est la validation que vous devez restaurer.

La machine CI peut même conserver un clone local du repo, à partir duquel vous pourrez effectuer cette récupération.

Source: probablement Continuous Delivery: versions de logiciels fiables grâce à l’automatisation de la génération, du test et du déploiement (Addison-Wesley Signature Series (Fowler))