Yesterday, I talked about using git reset for rollback operations and git revert operations. The differences between them are as follows:
git reset
The role of git reset is to restore the state of the Index or modify the position of the local branch HEAD. This command is suitable for starting a new branch from a commit point . For example, if we don't want any code after a commit , we can reset it locally to the specified commit, and then open a new branch to continue new development (the original branch has not changed at all on the remote).
Using git reset does not affect the remote branch, everything happens locally. If the rollback needs to affect the remote branch quickly, git revert should be used.
two cases
The first case: just commit locally, but not push to the remote branch, which can be achieved by the following command:
git reset --soft|--mixed|--hard <commit_id>
git push 本地分支名称 远程分支名称 --forceThe <commit_id> here is the SHA-1 of each commit, which can be viewed in the git log
--mixed: just roll back the git commit and index information to a certain commit version, and still keep the code submitted after the commit_id
--soft: only roll back the commit information to a certain version, not involving the rollback of index, The source code will be retained. If you still need to submit, just commit directly.
--hard: The source code will be rolled back to a certain version, and both commit and index will be rolled back to a certain version. (This method will change the source code of the local code repository)
Of course, after pushing the code, some people also use reset --hard <commit_id> to roll back the code to a certain version, but there will be a problem. The online code is still before the rollback, and there is no online commit and index. Change, when you modify the local code and submit it, you will find all conflicts......
git revert
If we don't want some old commits, and don't want to do it by modifying the code generated by these old commits and then resubmitting them, we can hand over this work to the revert command.
The principle of Git Revert: Make changes in the opposite direction based on the changes made by the commits you want to roll back , and then resubmit the code to bring the code to a state that could be achieved without these old commits.
If you don't understand the rollback strategy of git revert, maybe you can understand it: rolling back an old commit will inevitably lead to changes in the current latest code. For example, if a previous commit added a line of code, then the rollback is in Add one line of code to the same position. Git doesn't really throw away old commits, and if you throw them away, the history won't be able to track them. Therefore, the old commit is not actually moved, and Git just does it in reverse based on the old commit, which causes the latest code to change. Only when the changes caused by the rollback of the revert command are resubmitted, the revert command is truly completed and takes effect, otherwise the effect is only equivalent to modifying the files in the working tree. Note: After revert, you need to push to other users on the remote branch to see the changes that occurred in the rollback.
Problems with using git revert
Because git revert overwrites old commits with new commits, the overwritten old commits will not be adopted. If two branches (assuming master and A branch) are merged first, then rolled back with revert, and then merged (A merged into master), you will find that on the master branch, most of the changes before the first merge of branch A are missing. . This is because from the perspective of the order of time, the modification before the first merge of branch A occurs before revert, the revert occurs after, and revert discards the modification before the first merge of A, then Git considers you to merge again. A modification before the first time of A is discarded forever.
To solve this problem, the commit generated by revert needs to be reverted again (equivalent to restoring the old commit before).
Difference between the two
Note: git revert uses a new commit to roll back the previous commit, and git reset directly deletes the specified commit. It seems that the effect achieved is the same, but it is completely different.
First: If you have pushed to the online code base, after reset deletes the specified commit, your git push may cause a lot of conflicts, but revert will not;
second: If the existing branches and historical branches need to be merged in the future, The code of the reset recovery part will still appear in the history branch, but the commit submitted in the direction of revert will not appear in the history branch ( note!!! );
third: reset is in the normal commit history, deleting the specified commit, at this time HEAD is moved backward, and revert is to commit again in the normal commit history, but it is a reverse commit, and his HEAD is always forward.