Front-end - À propos de l'utilisation de git rebase -i HEAD pour modifier le code précédemment validé

Question

J'ai rencontré une telle situation aujourd'hui. Je l'étudie depuis longtemps et je ne sais pas quoi faire. Par exemple, aujourd'hui j'ai écrit beaucoup de fonctions, et elles ont toutes été commit. Par exemple, l'histoire de commit est probablement comme ceci :

commit message sont respectivement "1, 2, 3, 4", représentant le premier au quatrième Soumissions.
Supposons que je modifie le même fichier test.md à chaque fois. Après quatre soumissions, le contenu du fichier est :

1
2
3
4

signifie que chaque soumission ajoute une ligne, et le contenu correspondant est le commit message de cette soumission.
Puis maintenant, j'ai découvert qu'il y avait un oubli dans la deuxième soumission et qu'elle devait être modifiée. Utilisez simplement git rebase -i HEAD~3 pour accéder à la page interactive
. Comme indiqué ci-dessous, remplacez le pick devant la deuxième soumission par e pour modifier la deuxième soumission.

À l'heure actuelle, le contenu à l'intérieur de test.md ressemble à ceci :

1
2

Ensuite, je dois ajouter quelque chose. Par exemple, j'écris 5 dans une nouvelle ligne, puis git add ., git commit --amend et le deuxième commit est modifié. Ensuite, exécutez git rebase --continue, évidemment, car le contenu de la troisième ligne devrait être 3 lors de la troisième soumission, et à ce moment-là, j'ai ajouté quelque chose de nouveau dans la troisième ligne car j'avais besoin de compléter la deuxième soumission, donc. un conflit se produira certainement, ce conflit doit donc être résolu avant que git rebase --continue puisse être exécuté. À ce stade, le contenu du fichier est le suivant :

.

1
2
<<<<<<< HEAD
5
=======
3
>>>>>>> 1269f10... 3

Mais si je résous le conflit. . Ensuite, toutes les informations commit ultérieures seront perdues. .
Ensuite, la façon la plus stupide à laquelle je puisse penser est de revenir au deuxième commit point puis de tout réviser à nouveau. .
Mais si mes troisième et quatrième révisions sont particulièrement importantes. . Ce serait plus gênant.
Comment dois-je résoudre ce conflit pour que le deuxième commit puisse être modifié avec succès sans perdre le commit suivant. .
Peut-être que mon idée est fausse. . Avez-vous de bonnes idées les gars ? . Je m'agenouille et vous remercie tous. .

Answer 1

1. Le commit suivant ne doit pas être perdu. Après avoir terminé la fusion, exécutez git rebase --continue à nouveau.

2. Cependant, personnellement, je ne suis pas d'accord avec votre approche. En général, il n'est pas nécessaire de modifier de force le commit au milieu, il suffit de soumettre à nouveau un nouveau commit.