Créez un nouvel entrepôt, n'y placez qu'un seul fichier texte et effectuez respectivement 6 commits. À ce stade, git log --oneline devrait ressembler à ceci
Le contenu du fichier est le suivant
Je veux supprimer le commit 442452d mais conserver le commit e09949e, voici comment je procède
git reset --hard 260effc
Puis git cerise-pick e09949e
Un conflit éclate à ce moment, comme indiqué ci-dessous
Ce que je ne comprends pas, c'est pourquoi il y a un conflit. Logiquement, il devrait être corrigé directement. Il ne devrait pas ressembler à l'image ci-dessus. La soumission de e09949e ne devrait contenir que « 4 » et non « 3 », si c'est le cas. est toujours nécessaire. Si « 3 » est supprimé manuellement, à quoi ça sert de choisir ? Je peux simplement accéder au fichier et le supprimer. Ou y a-t-il un problème avec mon utilisation ? Demandez à Dieu de vous guider ! ! !
Pourquoi ne pas simplement git revert 442452d ?
Commit enregistre les modifications relatives et est lié aux lignes supérieure et inférieure du contenu modifié. Si la ligne précédente est perdue, un conflit sera signalé et devra être résolu manuellement. Si vos deux commits ne sont plus dans des fonctions liées, vous pouvez revenir directement.
De plus, utiliser cette méthode de réinitialisation --hard puis de sélection sélective n'est pas très bonne. D'autres collaborateurs peuvent avoir ajouté d'autres commits au milieu, rendant la gestion des conflits ultérieurs plus difficile.
Un meilleur scénario d'utilisation du Cherry-pick est lorsque vous souhaitez une fonctionnalité distincte d'une autre branche sur une branche.
Parce que
e09949e
ne contient que4
, ce qui correspond à la différence du commit précédent442452d
.Mais maintenant vous avez supprimé
442452d
et espérez faire pointer le nœud parent dee09949e
de442452d
vers260effc
. Il y aura effectivement un conflit.Je ne sais pas si mon explication est claire sans images animées. Si vous avez des questions, je vous suggère de commencer par lire ce tutoriel.