Translation: Li Wei
Revision: Sail
Translated from: Github
One of the most useful features in any version control system is the undo action. In Git, "undo" has a lot of meaning.
When you have completed a new commit, Git will store a snapshot of the current Time warehouse (repository) in time (snapshot), and you can use Git to roll back the project to any previous version.
Later in this article, I'll list a few common scenarios that need to be "undone" and show how to do it using Git.
One, undo a public modification
Scenario: You just pushed local modifications to GitHub with Git push, and you realized there was an error in the commit. You want to revoke this submission.
using the Undo command:git revert
what happened:git revert will create a new commit based on the opposite value of the given Sha. If the old commit is "matter", then the new commit is "anti-matter"-all the removed items in the old commit will be added to the new commit, and the additions to the old commit will be removed in the new submission.
This is the safest and simplest "undo" scenario for git, because it does not modify the history-you can now fix the error by git push, just after the revert.
Second, revise the last commit message.
Scenario: You just hit the wrong word in the last commit message, like you hit Git commit-m "fxies bug #42", and you realize that you should hit "Fixes bug #42" before executing git push.
use Undo command:git commit–amend or git commit--amend-m "Fixes bug #42"
what happened:git commit–amend will update and replace this error submission with a new commit that contains just the wrong commit of all the changes. Because there is no staged commit, the commit actually simply rewrites the previous commit information.
Iii. revoking local changes undo "local" changes
Scenario: When your cat climbs over the keyboard, the file you are editing is saved and your editor crashes at this point. You did not submit the code at this time. You expect to undo all of the changes in this file--fallback the file back to the last commit state.
using the Undo command:git checkout--
what happened:git checkout changes the files in the working directory (working directory) to a state known to git earlier. You can provide a name that expects a fallback branch or an exact SHA code, and Git also checks out the head--by default: The last commit of the current branch.
Note: "undo" changes in this way will really disappear. They will never be submitted. So git can't recover them. At this point, be sure to clarify what you are doing! (Perhaps you can use Git diff to determine)
Reset local Modify Reset "local" changes
Scenario: You've done some local commits (not yet push), but everything is awful and you want to undo the last three commits-as if they never happened.
use Undo command:git reset or git reset--hard
what happened:git reset keeps your warehouse record back to the submission of the last SHA rep that you specified, and those submissions are as if they never happened. By default, git reset retains the working directory (working directory). Although these commits have disappeared, the content is still on disk. This is the safest approach, but usually you want to use a command to "undo" all commits and local modifications--then use the--hard parameter.
V. Undo local Post Redo Redo after undo "local"
Scenario: You've already submitted some content and used Git reset–hard to undo the changes (see above) and suddenly realize: you want to revert these changes!
Use the Undo command:git reflog and git reset, or git checkout
what happened:git reflog is a great way to restore your project history. You can recover almost any submitted content via Git reflog.
You may be familiar with the git log command, which displays a list of commits. Git reflog is similar, except that git reflog shows a list of head changes.
Some notes:
1. Only the head will change. When you switch branches, the head changes when you commit a change with git commit, or when you revoke a commit with git reset. But when you use git checkout--the head doesn't change. (as mentioned above, those changes are not committed at all, so Reflog will not be able to help us recover)
2. Git reflog does not always exist. Git will periodically clean up those objects that are "unreachable" (unreachable). Do not expect to be able to find a record of submissions in Reflog a few months ago.
3. Reflog is just your personal. You can't use your reflog to recover uncommitted submissions from other developers.
So, how to use reflog reasonably to retrieve the previous "unfinished" Submissions? It depends on what you are going to do:
1. If you want to restore the project history to a commit, then use git reset--hard
2. If you want to recover one or more files from a commit in the working directory (working direcotry) and do not change the commit history, use Git checkout--
3. If you want the exact rollback to a commit, then use Git cherry-pick.
Vi. those matters related to the branch Once more, with branching
Scenario: You commit some changes, and then you realize that you are on the Master branch, but you expect the commits to be executed on the feature branch.
use Undo command:git branch feature, git reset--hard origin/master, and git checkout feature
What happened: you might be using Git checkout-b to build a new branch, which is a convenient way to create and check out a branch-but you don't really want to switch branches right away. Git branch feature will create a branch called feature, which points to your recent commit, but you still stay on the master branch.
git reset--hard the master back to Origin/master and ignores all new commits. Don't worry, those submissions remain on the feature.
Finally, git checkout switches the branch to feature, which retains all of your recent work intact.
Seven, do more with less processing branch Branch in time saves nine
Scenario: You create a new feature branch based on master, but the master branch is far behind and Origin/master. Now that the master branch is synchronized with the origin/master, you expect to be able to commit the code immediately under feature, and not in the case of being far behind master.
using the Undo command:git checkout feature and Git rebase master
What happened: you might have knocked on the command: Git reset (but not--hard, intentionally saving the submissions on disk), then tapped Git checkout-b, and then resubmitted the changes, but then you would lose the local commit record. However, a better approach:
There are a few things you can do with git rebase master:
1. First, it locates the common ancestor node (common ancestor) between the branch and master you are currently checking out.
2. It then resets the currently checked-out branch to the ancestor node (ancestor) and temporarily saves all subsequent commits.
3. Finally, it advances the current checkout branch to the end of master, and submits the changes to the staging area again after Master's last commit.
Viii. Batch Undo/Retrieve Mass Undo/redo
scenario: You begin to develop functionality toward a given goal, but halfway you feel better with another method. You already have more than 10 commits, but you just want some of them, the others can be deleted.
using the Undo command:git rebase-i
What happened:-I set the rebases to "interactive mode (interactive modes)". Rebase starts doing the same as discussed above, but when you re-execute a commit, it pauses and lets you modify each commit.
Rebase–i will open your default text editor and then list the commits that are being executed, just like this:
The first two columns are the most critical: a SELECT command, which selects the corresponding commit based on the SHA code in the second column. By default, Rebase–i will assume that each change is being committed through the pick command.
To undo a commit, delete the corresponding line directly in the editor. If you no longer need these wrong commits in your project, you can delete the lines in line 1th and 3-4 directly.
You can use the reword command if you want to keep the commit but modify the submission information. That is, change the command keyword pick to reword (or R). You may now want to modify the commit message immediately, but this will not take effect--rebase–i will ignore everything after the Sha column. The existing submissions will help us remember what 0835FE2 stands for. After you've knocked out the rebase–i command, Git starts prompting you to rewrite those new commit messages.
If you need to merge 2 commits, you can use squash or fixup commands, such as:
Squash and fixup are all "up"-those that use these merge commands (Editor's note: squash, fixup) will merge with their previous commits: 0835fe2 and 6943e85 will be merged into one commit, and 38f5e4e and af67f82 will be merged into another commit.
When you use squash, Git will prompt you to fill in a new commit message, and fixup will give you the first commit in the list. In, Af67f82 is a "ooops" message because the submission is already the same as 38f5e4e. But you can write submissions for the new submissions that 0835fe2 and 6943e85 merge.
When you save and exit the editor, Git will execute your commit in the order from top to bottom. You can modify the order in which commits are executed before saving these commits. If necessary, you can merge af67f82 and 0835fe2, and you can sort:
Nine, fix the previous commit fix an earlier commit
Scenario: A file was dropped in the previous commit, and it would be nice if the previous commit could have something you left behind. You have not push, and this submission is not the most recent commit, so you cannot use Commit–amend.
using the Undo command:git commit--squash and git rebase--autosquash-i
what happened:git commit–squash will create a new commit, which might look like this "squash! Earlier commit ". (You can also write these submissions, Commit–squash just to save you typing).
If you don't want to write information for a merged submission, you can also consider using the command git commit--fixup. In this case, you might use commit--fixup, because you only want to use the previous commit information in rebase.
Rebase--autosquash–i will launch the rebase interaction editor, and the editor will list any completed squash! and fixup! commits, such as:
When using--squash and –fixup, you may not be able to remember the SHA code of a commit you want to fix-just know that it may be before one or five commits. You might be able to use Git's ^ and ~ operators to retrieve them manually. head^ represents the first commit of the head. Head~4 represents 4 commits before head and adds up to a total of 5 commits in the first time.
Ten. Stop tracking a file that has been tracked stop tracking a tracked files
Scenario: You accidentally add Application.log to the warehouse, and now every time you run the program, Git prompts Application.log for a unstaged commit. You write "*.log" in. Gitignore, but it's still useless--how do you tell Git to "undo" the changes to this file?
use Undo command: git rm--cached Application.log
what happened: although. Gitignore prevents git from tracking changes to files, even if the files that were not previously tracked are present, but once the file is added or commit,git it will start to keep track of the change in the file. Similarly, if you use Git add–f to "force" add, or overwrite. Gitignore,git will continue to monitor the change. So it's best not to use –f to add. gitignore files later.
If you want to remove files that should be ignored, git rm–cached can help you and keep those files on disk. Because this file is now ignored, you will not see it in git status and will not commit the file again.
The above is how to undo on git. If you want to learn more about git command usage, you can follow the relevant documentation below:
Checkout
Commit
Rebase
Reflog
Reset
Revert
Rm
Original address: Github
Address: HTTP://WWW.JOINTFORCE.COM/JFPERIODICAL/ARTICLE/SHOW/796?M=D03
"Go" How to undo everything in Git