Non seulement les développeurs débutants, mais aussi les professionnels passionnés doivent recourir à l'annulation de tout changement. Et puis, la première chose qui me vient à l'esprit est la commande git revert, comme moyen le plus sûr. Et il y a des écueils dont je veux vous parler.
Prenons une situation simple: un développeur décide d'implémenter des fonctions mathématiques. Mais à mi-chemin, il se rend compte qu'il serait bon de décomposer cette tâche, disons, en deux sous-tâches:
- Mettre en œuvre des opérations arithmétiques (addition, soustraction, division, etc.)
- Mettre en œuvre des opérations numériques (valeur maximale, valeur minimale, module d'un nombre, etc.)
Ce sera plus facile à vérifier et à tester. Mais il a déjà commencé à le mettre en œuvre, les commits ont déjà été créés, et que faire? Ne réécrivez pas la même chose!
Considérez un arbre de validation. On voit que notre développeur a créé une branche functions, la classe Arithmetic , qui est responsable de l'implémentation des opérations arithmétiques (commit A ), et la classe Numerical , qui est responsable de l'implémentation des opérations numériques (commit N ). Au total, il y a deux classes et deux commits.
git revert
, , functions numerical arithmetic. . git revert N arithmetic git revert A numerical. !
— .
? Arithmetic, Numerical!
, git revert . 4 :
A ⟶ N ⟶ revert A ⟶ revert N revert .
git reset
, reset, revert . … . , .
git rebase
— git rebase .
numerical arithmetic
git rebase -i –root , pick drop. . numerical:
.
master .
Cette méthode fonctionne, uniquement si vous travaillez dans une branche privée, mais si ces manipulations sont effectuées dans une branche partagée, alors lors de la publication ( git push), gitelle signale que la branche est obsolète, car il n'y a pas de commits dedans et annule la publication.
Afin de ne pas lutter avec git, essayez de décomposer les tâches à l'avance, sinon vous risquez de prendre une surprise. Avez-vous rencontré de telles situations, et si oui, comment vous en êtes-vous sorti?