Summary of some undo and resume commands in Git

Time:2019-11-6

Undo a “public” change

Scenario: you have executed git push and sent your changes to GitHub. Now you realize that one of these commits is problematic and you need to undo that one

Method:

Copy code

The code is as follows:

git revert <SHA>

Principle: git revert will generate a new commit, which is the opposite (or reverse) of the commit corresponding to the specified Sha. If the original commit is “substance”, the new commit is “antimatter” – any content deleted from the original commit will be added back in the new commit, and any content added in the original commit will be deleted in the new commit.

This is git’s safest and most basic undo scenario, because it doesn’t change history – so you can now git push a new “reverse” commit to offset your erroneous commit.

Undo “local” changes

Scene: a cat walks past the keyboard, accidentally saves the changes, and then destroys the editor. However, you have not committed these changes. You want to restore all the contents of the modified file – just like the last time commit did.

Method:

Copy code

The code is as follows:

git checkout — <bad filename>

Principle: git checkout will change the files in the working directory to a state recorded before GIT. You can provide a branch name or specific Sha that you want to return, or by default, GIT will think that what you want to check out is head, the last commit of the current checkout branch.

Remember: any changes you “undo” in this way will really disappear. Because they’ve never been submitted, GIT can’t help us recover them later. Make sure you know what you’re throwing away in this operation! (maybe you can use git diff to confirm first.)
Git warehouse is withdrawn to the status of the previous submission

Copy code

The code is as follows:

$ git checkout <SHA>

“” is the first 8 to 10 characters in the hash code you want to view This command detaches the < head > pointer from the detach, allowing you to view the code without checking out any branches of the check out — detaching from the head is not as scary as it sounds. If you want to commit changes in this case, you can do so by creating a new branch:

Copy code

The code is as follows:

$ git checkout -b <SHA>

To get back to the current work progress, just check out your previous branch.

Undo last code commit
Sometimes you may accidentally submit a wrong document or miss something in the first place. The following three steps can help you solve this problem.

Copy code

The code is as follows:

$ git reset –soft HEAD~1
#Make necessary changes to working documents
$ git add -A .
$ git commit -c ORIG_HEAD

When you execute the first command, GIT will move the head pointer backward to the previous commit before you can move the file or make necessary changes.

Then you can add all the changes, and when you execute the last command, GIT will open your default text editor, which will contain the information from the last commit. You can modify the submission if you want, or you can skip this step by using – C instead of – C in the final command.

Undo merge
To undo the merge, you may have to use the recover command hard reset to return to the last committed state. The work of merge is basically to reset the index, update different files in the working tree, that is, different files between the currently submitted () code and the code pointed by the head cursor; however, merge will retain the differences between the index and the working tree (for example, those changes that are not tracked).

Copy code

The code is as follows:

$ git checkout -b <SHA>

Restore after undo local changes

Scenario: you submit several commit, then undo the changes with git reset — hard (see the previous paragraph), and then you realize: you want to restore the changes!

Method:

Copy code

The code is as follows:

git reflog

and

Copy code

The code is as follows:

git reset

or

Copy code

The code is as follows:

git checkout

Principle: git reflog is a great resource for recovering project history. You can recover almost anything – anything you’ve committed – just through reflog.

You may be familiar with the GIT log command, which displays a list of commits Git reflog is similar, but it shows a list of times when the head has changed

Some precautions:

It’s just about the head change. When you switch branches, commit with git commit, and undo commit with git reset, the head will change, but when you undo with git checkout — < bad filename > (as we mentioned earlier), the head will not change – as mentioned earlier, these changes have never been committed, so reflog can’t help us recover them.
Git reflog will not last forever. Git regularly cleans up “out of use” objects. Don’t expect the submission of a few months ago to remain there.
Your reflog is yours, just yours. You can’t use git reflog to restore a commit that another developer hasn’t pushed.

2015127114148155.png (1429×644)

Massive undo / restore

Scenario: you start implementing a feature in one direction, but halfway you realize that the other is better. You’ve submitted a dozen times, but you only need a part of it now. You want all the other unwanted submissions to go away.

Method:

Copy code

The code is as follows:

git rebase -i <earlier SHA>

Principle: – I parameter enables rebase to enter “interactive mode”. It starts out like the rebase discussed earlier, but it pauses and allows you to modify each commit in detail before any commits are redone.

Rebase – I will open your default text editor, which lists the candidate submissions. As follows:

2015127114214865.png (1459×495)
The first two columns are keys: the first is the selected command, corresponding to the commit determined by Sha in the second column. By default, rebase – I assumes that every commit is applied through the pick command.

To discard a commit, just delete the line in the editor. If you don’t need the wrong submissions in the project, you can delete lines 1, 3 and 4 in the above example.

If you need to keep the content of the commit and edit the commit message, you can use the reword command Replace the pick in the first column with word (or R directly). Some people think it’s OK to rewrite the commit message directly here, but it doesn’t work – rebase – I will ignore anything in front of the Sha column. The text behind it is just to help us remember what 0835fe2 is for. After you complete the rebase-i operation, you will be prompted to enter any commit messages you need to write.

If you need to combine the two commit commands, you can use the squash or fixup command as follows:

2015127114237973.png (1449×339)
Squash and fixup merge “up” – a commit with these two commands is merged into its previous commit. In this case, 0835fe2 and 6943e85 will be combined into one commit, and 38f5e4e and af67f82 will be combined into another commit.

If you choose square, GIT will prompt us to give a new commit message to the newly merged commit; fixup will give the first commit message in the merge list directly to the newly merged commit. Here, you know that af67f82 is a “over… You will keep the commit message of 38f5e4e as, but you will write a new message for the new commit that combines 0835fe2 and 6943e85.

When you save and exit the editor, GIT will use your commit from top to bottom. You can change the order of application by changing the order of commit before saving. If you like, you can also combine the af67f82 and 0835fe2 by arranging as follows:
2015127114254840.png (1445×326)