Front-end - About using git rebase -i HEAD to modify previously committed code
漂亮男人
漂亮男人 2017-05-02 09:32:51
0
1
638

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. .

漂亮男人
漂亮男人

reply all(1)
曾经蜡笔没有小新
  1. The subsequent commit should not be lost. After completing the merge, execute it againgit rebase --continue.

  2. 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.

Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template