During the development of multi-person cooperative programs, we sometimes encounter incorrect submissions. At this time, we hope to cancel the submission operation and return the program to the way it was before submission. The operations are:
Rollback (reset) : Reset is a complete rollback to the specified commit version. All commits after the commit will be cleared; no records will be generated after reset is executed.
Revert : Revert only undoes the modification of the specified commit and does not affect subsequent commits. Records will be generated after revert is executed.
Both reset and revert have the meaning of undoing and rolling back, but each has its own merits, and the difference is still very big, so which command to use must be decided based on the actual situation. To understand these, you still need to learn more basic knowledge of git.
Four work areas of Git
-
Workspace : Also known as working directory and working copy. Simply put, it is the directory containing project files that we see after cloning. Our daily development operations are also carried out in the workspace.
-
Local warehouse (.git) : There is a hidden directory .git in the workspace, which is the database of the Git local warehouse. The project files in the workspace are actually obtained from checkout here, and the modified content is finally submitted and recorded in the local warehouse.
Tips: Do not manually modify the contents of the .git directory -
Staging area : Also called cache area, it is logically located between the workspace and the local warehouse. Its main function is to mark modified content. The content in the staging area will be recorded in the local warehouse at the next submission by default.
-
Remote warehouse : Team collaboration often requires specifying a remote warehouse (usually one, but there can be multiple). Team members achieve team collaboration by interacting with the remote warehouse.
A basic Git workflow is as follows:
-
Modify files in workspace
-
Temporarily save files, store files in the temporary storage area
-
Submit changes from the staging area to the local warehouse
-
Push from local warehouse to remote warehouse
Git version management and understanding of HEAD
Every time you commit using git, Git will automatically string them into a timeline , and this timeline is a branch.
If there is no new branch, there is only one timeline, that is, only one branch. In Git, this branch is called the main branch, that is, the master branch.
There is a HEAD pointer pointing to the current branch (if there is only one branch, it will point to master, and master points to the latest commit ).
Each version will have its own version information, such as a unique version number, version name, etc. As shown below, assume there is only one branch:
Terms you still need to know
-
HEAD : This is the alias of the top of the current branch version, which is your most recent commit on the current branch.
-
Index: Index, also known as staging area, refers to a set of files that will be submitted next. He is also the commit who will become HEAD's father
-
Working Copy : working copy represents the set of files you are working on
-
Flow : Process and planning of git project management. For example, branch planning: Master/Devlop branch, Feature branch, Release branch, Hotfix branch
Understand how Git handles branches
-
The commit operation calculates hash checks for each file in each directory , and then saves these checksums as tree objects in the Git repository .
-
Subsequently , Git creates a commit object. The commit object will contain a pointer to a snapshot of the staging content . Also included is the author's name and email address, the information entered when submitting, and a pointer to its parent object. This way, Git can reproduce the saved snapshot when needed.
-
Then the file snapshot of the current version will be saved to the Git repository (Git uses blob objects to save them), and finally the checksum will be added to the staging area to wait for submission.
-
The submission object generated by the first submission has no parent object, the submission object generated by the ordinary submission operation has one parent object, and the submission object generated by the merger of multiple branches has multiple parent objects.
There are five objects in the Git repository:
Three blob objects (which hold file snapshots), a tree object (which records the directory structure and blob object index), and a commit object (which contains pointers to the aforementioned tree objects and all commit information).
What Git saves is not file changes or differences, but a series of file snapshots at different times .
HEAD refers to the current snapshot
This command mainly cooperates with the three parameters of reset--hard,--mixed and--solf to process this modification.
-
HEAD~1 refers to rolling back a snapshot, which can be abbreviated as HEAD~
-
HEAD~2 refers to rolling back two snapshots.
-
HEAD^ is mainly used to control the direction of rollback after merge.
-
HEAD~ is the number of steps to go back
Delete remote and local commit records via command line
Common code rollback scenarios
Rollback scenario: only when workspace is modified
When a file is modified in the workspace but has not yet been submitted to the staging area and local warehouse, you can use git checkout -- file name to roll back these modifications.
Execute the following command to roll back the modifications to the workspace:
git checkout -- build.sh
However, it is important to note that these changes are not submitted to the Git repository. Git cannot track their history and will be discarded once rolled back.
Example: Check with git status. Modifications that have not been submitted to the staging area appear in the "Changes not staged for commit:" section.
Rollback scenario: when added to the staging area
That is, if you have executed git add and added it to the temporary storage area, but have not yet committed it, you can use git reset HEAD file name to roll back.
Execute the following command to roll back the modifications to the staging area:
git reset HEAD build.sh
After rollback, the workspace will retain the changes to the file. You can re-edit and submit, or git checkout -- file name to completely discard the changes.
Rollback scenario: when commit has been made but has not been pushed yet
That is, it has been submitted to the local code base, but has not been pushed to the remote end. At this time, you can use the git reset command. The command format is:
git reset <commit to be rolled back to> or git reset --hard <commit to be rolled back to>
It should be noted that the commit to be rolled back is provided, and the commit records after this commit will be discarded .
Rollback scenario: when pushed to the remote end
Notice! You cannot use "git reset" at this time, you need to use "git revert"!
Say important things three times! The reason for this emphasis is because "git reset" will erase history and will cause various problems when used on records that have been pushed; and "git revert" is used to roll back the content of a certain submission and generate a new submission. , will not erase history.
| Order | Whether to erase history | Applicable scene |
|---|---|---|
| git reset | Yes, the rollback history will disappear | Local unpush records |
| git revert | No, the history record is retained and the commit record is regenerated after rollback. | Roll back pushed content |
git reset rolls back a commit
Make sure to perform a forced rollback before anyone else commits - reset HEAD (the top version of the current branch) to another commit
git reset --hard HEAD~2
-
git reset code withdrawal
-
--hard and --soft and default mixed
-
--hard is to delete the commit record and not save the changes made to the deleted record - reset HEAD and return to another commit
Reset the index to reflect the changes in HEAD, and reset the working copy so that it matches exactly. This is a dangerous and destructive action, and data may be lost!
-
--soft deletes the last two commit records, but also saves the changes made by the commit - tells Git to reset HEAD to another commit, but that's it.
Neither index nor working copy will make any changes. All changesets between the original HEAD and the commit you reset to are placed in the stage (index) area.
-
--mixed is the default parameter for reset. It will reset HEAD to another commit, and reset the index to match HEAD, but that's where it ends.
The working copy will not be changed. All changes on the branch from the original HEAD (commit) to the commit you reset to will be saved in the working area as local modifications (marked as local modification or untracked via git status), but are not staged status, you can re-examine and then make modifications and commits
-
-
The number represents how many versions to roll back
git push -f force overwrite
Remember that git reset does not generate commits, it only updates a branch (branch itself is a pointer to a commit) to point to another commit (Head and branch Tip move at the same time to remain consistent). The rest is only for the index and work tree ( working directory). git checkout xxxCommit only affects HEAD. If xxxCommit is consistent with a branch tip, then HEAD matches the branch. If xxxCommit is not consistent with any branch tip, git enters the detached HEAD state.
If you have already submitted the code, how to delete the remote historical submission record?
Delete commits in the middle of the commit record
git reset --hard 2b93fa8bdc8a1ca8e0c7498bd56460e6d1c408d1 //Follow the version number
git push origin HEAD --force
Turn off protected permissions on branches
However, if you follow the above command, the operation cannot be successful. For example, the following prompt will be reported:
! [remote rejected] master -> master (pre-receive hook declined)
Permissions on this branch are restricted
settings/repository/Protected Branches ->un protected
git revert abandons a commit
The commit before git revert will still remain in the git log , and the revocation will be treated as a new commit.
Revert and reset are similar in operation, the difference is:
-
git revert is to undo an operation. The commits before this operation will be retained.
-
git reset is to undo a certain commit, but subsequent modifications will be returned to the staging area.
-
The git reset operation will roll back the version to the specified commit, and all operations after the specified commit will be undone.
-
Git revert undoes the modifications of the specified commit and generates a new commit.
git rebase rebuilds the commit order
git rebase --onto
Then start deleting commit records 2 and 3 [You may encounter conflicts when executing rebase. Resolving conflicts is beyond the scope of this article.
git rebase --onto master~3 master~1 master
Delete a commit record
git rebase -i d65f0fba23f2113ece6fbb3d104a33a1a8a80406
It will enter vim mode, just change pick to drop. For specific operations, check: https://www.jianshu.com/p/520f8661659c
By the way, I recommend: " Merge or rebase in git? Git Jihad merge vs rebase 》
Reference article:
The art of Git code rollback and retrieval The art of Git code rollback and retrieval - CODING - SegmentFault Sifu
Deep understanding of the differences between git reset soft, hard, and mixed https://www.cnblogs.com/kidsitcn/p/4513297.html
git understands HEAD^ and HEAD~ git understands HEAD^ and HEAD~_Claroja's blog-CSDN blog
git reset revert rebase difference git reset revert rebase difference_git rebase reset difference_lainegates' blog-CSDN blog
The difference between git reset, rebase and revert The difference between git reset, rebase and revert_printf_goth's blog-CSDN blog
The difference between git reset and git revert https://segmentfault.com/a/1190000019153248
Code rollback: differences and connections between git reset, git checkout and git revert https://www.cnblogs.com/houpeiyong/p/5890748.html
What is the difference between reset and revert in git? What is the difference between reset and revert in git-git-PHP Chinese website
Git's two methods for restoring the previous version, reset and revert (detailed graphic and text explanation) Git's two methods for restoring the previous version, reset and revert (detailed graphic and text)_git reset revert_Youxiao Tianya's Blog-CSDN Blog
Reprint the article on this site " Full solution of head/reset/revert/rebase code rollback: The principle behind git submission record ",
please indicate the source: Full solution of head/reset/revert/rebase code rollback: The principle behind git submission record - Some daily small combinations used by git - Zhou Junjun's personal website