In the process of iterative development of versions, I believe many people have made mistakes (at least a few times). In this case, rookie programmers may be shocked and nervous. And senior programmers will smile, touch the shiny forehead, and then quietly back version.
For version rollback, we often use two commands:
- git reset
- git revert
What’s the difference between these two orders? Don’t worry. We’ll introduce it later.
Suppose our system now has the following submissions:
Where: A and B are normal submissions, and C and D are error submissions. Now, we want to return C and D. At this time, the head pointer points to D commit (5lk4er). We just need to move the head pointer to B submit (a0fvf8) to achieve the goal.
As long as you have git foundation, you will think of it
git resetOrders. The complete command is as follows:
git reset --hard a0fvf8
After the command is run, the head pointer will move to B submit, as shown in the following figure:
At this time, the head pointer of the remote warehouse is still the same, still on the D submission. So, if you use it directly
git pushCommand, you will not be able to push the changes to the remote repository. At this point, you can only use the
-fOption to force the submission to the remote warehouse:
git push -f
The obvious drawback of using this method to rollback code is that it will make the head pointer move back, thus losing the subsequent submission information. In the future, if you suddenly find out what wonderful ideas C and D are, they have already disappeared in the long river of history.
Moreover, some companies (such as Liangxu’s) explicitly prohibit the use of GIT reset command to rollback code for the same reason. So, we need to find a command that can both rollback the code and save the wrong commit. At this point,
git revertOrders come in handy.
Git revert is used to create a new version by reverse doing. The content of this version is the same as the target version we want to go back to, but the head pointer points to the newly generated version instead of the target version.
Using the GIT revert command to implement the above example, we can do this: first revert D, then revert C (if there are multiple submissions that need to be returned, we need to revert from new to old)
git revert 5lk4er git revert 76sdeb
Here, two new submitted files will be generated: D ‘and C’, as shown in the following figure:
There are only two submissions that need to be reverted. We can go back one by one. But what if there are dozens? One by one, fallback must be inefficient and error prone. We can use the following methods for batch fallback:
git revert OLDER_COMMIT^..NEWER_COMMIT
At this time, the wrong submission C and D are still reserved, and there will be a basis for the future throwing of the pot. Moreover, if you operate in this way, the head pointer moves backward and can be used directly
git pushThe command is pushed to the remote warehouse. This practice is encouraged by enterprises.
Let’s give a more difficult example.
Suppose there are three submissions, but unfortunately, the wrong one is in the middle. As shown in the figure below:
At this time, it is obviously not feasible to reset the head pointer to a submission by using git reset command directly, because C submission is correct and needs to be retained. First submit C and B batch all back, then use
cherry-pickCommand to regenerate the C submission into a new submission C ”, which realizes the requirement of backtracking the B submission. The whole process is as follows:
Finally, recently a lot of small partners come to me for helpLinux learning RoadmapAccording to my own experience, I stayed up late for a month in my spare time and organized an e-book. Whether you are interviewing or self-improvement, I believe it will help you!
Free to you, just ask you to give me a praise!
Also hope that a small partner can join me to make this e-book more perfect!
What’s the gain? I hope the old fellow will take three strikes to show this article to more people.