In the process of iterative development, I believe that many people will have the time of error submission (at least Liangxu has had this experience several times). In this case, rookie programmers may drive a shock, nervous at a loss. And senior programmers will smile, touch the shining forehead, and then silently version back.
For version fallback, we often use two commands:
- git reset
- git revert
What’s the difference between the two orders? Don’t worry. We’ll introduce it in detail later.
Suppose our system now has the following submission:
Where: A and B are normal commits, while C and D are error commits. Now, we want to return C and D. At this point, the head pointer points to D commit (5lk4er). We only need to move the head pointer to B commit (a0fvf8) to achieve the goal.
As long as you have git foundation friends, you will think of it
git resetCommand. The complete command is as follows:
git reset --hard a0fvf8
After the command runs, the head pointer will move to B submission, as shown in the following figure:
At this time, the head pointer of the remote warehouse remains unchanged and is still in the D submission. So, if you use it directly
git pushYou cannot push the changes to the remote repository. In this case, you can only use
-fOption to force the submission to the remote repository:
git push -f
The disadvantage of using this method to rollback code is obvious, that is, it will cause the head pointer to move back, thus losing the subsequent submission information. What a wonderful idea that they would have disappeared in the river in the future.
In addition, some companies (such as Liangxu’s company) prohibit using git reset command to rollback code for the same reason. So we need to find a command that can both roll back the code and save the error submission. At this time,
git revertOrders come in handy.
Git revert creates a new version by doing reverse. The content of this version is the same as the target version we want to fallback to, but the head pointer points to the newly generated version, not the target version.
To implement the above example with the GIT convert command, we can do this: first reverse D, then reverse C (if there are multiple submissions that need to be rolled back, we need to reverse from new to old)
git revert 5lk4er git revert 76sdeb
Two new commits will be generated here: D ‘and C’, as shown in the following figure:
There are only two submissions that need to be reverted, and we can go back one by one. But what if there are dozens? One by one, it must be inefficient and error prone. We can use the following methods for batch rollback:
git revert OLDER_COMMIT^..NEWER_COMMIT
At this time, the wrong submission C and D are still retained, and there is a basis for future boiler tossing. Moreover, 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 exactly what enterprises encourage.
Let’s take a more difficult example.
If there are three commits now, unfortunately, the wrong commit is right in the middle. As shown in the figure below:
At this time, it is obviously not feasible to use git reset command to reset the head pointer to a submission, because the C submission is correct and needs to be retained. First, return the C submission and batch B to use
cherry-pickThe command regenerates the C commit to a new commit C ”, which implements the requirement to rollback the B commit. The whole process is as follows:
Official account: good Linux