Je suis actuellement dans la situation où certains de mes derniers commits ont écrasé le contenu d'un ancien commit.
J'utilise l'extension de l'outil git, depuis l'interface graphique, je peux extraire une certaine révision - un commit.
J'ai donc extrait la révision et je peux voir localement que les fichiers existent - mais il ne semble pas y avoir quoi que ce soit à valider? Ce qui, je suppose, a du sens?
Comment repousser un commit précédent?
4 Réponses :
avez-vous essayé de sélectionner le commit en haut? git cherry-pick
Supposons que nous ayons un scénario dans lequel notre journal de validation précédent est comme
git cherry-pick -n <commit-4 sha1>
Deux choses que nous souhaitons peut-être maintenant.
Nous voudra peut-être supprimer notre tout mauvais commit git et voudra passer à la dernière bonne étape de commit. Dites comme suit
git status commit-4 [ good commit ] commit-1 [ bad commit ] commit-2 [ bad commit ] commit-3 [ bad commit ] commit-4 [ good commit ] commit-5 [ good commit ]
Nous pouvons le faire en nous reposant les trois premiers commit comme ceci
git reset --hard HEAD~3 # for n number of last commit reset git reset --hard HEAD~n
Je dois mentionner que c'est très moyen difficile d'annuler votre travail. Veuillez le faire lorsque vous savez parfaitement pourquoi vous aimez faire cela.
Vous pouvez placer votre commit-4 en haut de ceux-ci
git status commit-4 [ good commit ] commit-5 [ good commit ]
Vous pouvez faire ceci comme suivant
git status commit-1 [ bad commit ] commit-2 [ bad commit ] commit-3 [ bad commit ] commit-4 [ good commit ] commit-5 [ good commit ]
Ceux-ci placeront commit-4 en tête de ces mauvais commit.
Je suggère l'une des deux manières suivantes:
Si votre nouveau commit n'a rien apporté d'utile. Et il a simplement annulé ce que vous aviez fait dans votre précédente utilisation de commit git-revert. Cela créera un nouveau commit qui annulera tout ce que le commit rétabli a fait.
Dans la ligne de commande git, vous identifiez le mauvais commit avec
git cherry-pick -n fedc9876
keep son ID (exemple 12345abcd). Puis rétablissez ce commit
git cherry-pick fedc9876
Si vos nouveaux commits ont fait quelque chose de bien en plus de casser vos anciens commits, vous pouvez choisir les anciens commits que vous aimez avoir. Il appliquera les mêmes changements de code que le commit précédent. Cependant, cela deviendra un nouveau commit. Cela permet à votre branche de rester cohérente avec les anciens pulls.
Identifiez d'abord le commit que vous souhaitez appliquer à nouveau avec git log et
conservez l'ID (par exemple fedc9876)
git revert 12345abcd
Si vous souhaitez avoir plus de contrôle sur la sélection de cerises, utilisez l'option -n pour empêcher la validation immédiate
git log
J'ai donc fini par créer une nouvelle branche et j'ai déplacé mes fichiers là-bas, J'ai eu plus tard un problème similaire où j'ai remarqué que la branche locale et la dénomination de la branche distante n'étaient pas les mêmes.
J'avais effectué un git push -f, car je voulais rebaser avec notre maître, mais le nom de la branche locale n'était pas le même que celui de la branche distante, ce qui signifie qu'une branche distante a été créée et que l'une contenait le nouveau commit.
Il semble que gitExtension crée par défaut une branche locale avec une majuscule - ce qui n'est pas toujours le cas lorsque je crée une branche distante.
Veuillez ne pas pousser -f lorsque vous re-basez une branche. Rebase est ok si une branche est uniquement locale. Mais dès que vous obtenez une branche à partir de origin , rebasez-la et forcez-la à nouveau, vous cassez l'historique de validation pour tout le monde. Ne le faites même pas lorsque vous utilisez l'origine seule. Vous entraînez de mauvaises pratiques et vous pourriez casser des choses pour vous-même si vous avez plus d'un clone. Soit vous créez de nouvelles branches, soit corrigez votre erreur sans changer l'historique. C'est souvent OK quand les commits montrent que vous avez fait une erreur et que vous l'avez modifiée.
Je ferais attention à la réinitialisation, comme @YesThatIsMyName l'a suggéré, car les réinitialisations (matérielles) sont potentiellement destructrices. Au lieu de cela, il existe une solution à votre problème dans cette réponse :
git show COMMIT_ID | git applyQu'entendez-vous exactement par "écrasé", voulez-vous dire que les modifications ont été annulées ou voulez-vous dire que quelqu'un a supprimé le commit de l'historique?
N'utilisez PAS de réinitialisation tant que vous ne connaissez pas les conséquences. Cette commande est donnée comme une astuce pour la plupart des cas étranges et conduit souvent à encore plus de problèmes qu'auparavant.