I encountered such a situation today. I have been studying it for a long time and don’t know what to do. For example, today I wrote a lot of functions, and they have all been commit
. For example, the history of commit
is probably like this: commit message
are "1, 2, 3, 4" respectively, representing the first to the fourth Submissions.
Suppose I modify the same file test.md
every time. After four submissions, the file content is:
1
2
3
4
means that each submission adds one line, and the corresponding content is the commit message
of this submission.
Then now I found that there was an oversight in the second submission and needed to be modified. Just use git rebase -i HEAD~3
to enter the
interactive page. As shown below, then change the pick
in front of the second submission to e
to modify the second submission.
At this time, the content inside test.md
looks like this:
1
2
Then I need to add something. For example, I write 5
in a new line, and then git add .
, git commit --amend
and the second commit
is changed. Then execute git rebase --continue
, obviously, because the content of the third line should be 3
when submitted for the third time, and at this time I added something new in the third line because I needed to supplement the second submission. , so a conflict will definitely occur, so this conflict must be resolved before git rebase --continue
can be executed. At this time, the file content is as follows:
1
2
<<<<<<< HEAD
5
=======
3
>>>>>>> 1269f10... 3
But if I resolve the conflict. . Then all the subsequent commit
information will be lost. .
Then the stupidest way I can think of is to go back to the second commit
point and then revise everything again. .
But if my third and fourth revisions are particularly large. . That would be more troublesome.
How should I resolve this conflict so that the second commit
can be modified successfully without losing the subsequent commit
. .
Maybe my idea is wrong. . Do you guys have any good ideas? . I kneel down and thank you all. .
The subsequent commit should not be lost. After completing the merge, execute it again
git rebase --continue
.However, I personally don’t agree with your approach. Generally, there is no need to forcibly change the commit in the middle, just resubmit a new commit.