About Git's Undo Command: How to Undo Everything in Git

One of the most useful features of any version control system is the ability to "undo" an operation. In Git, "undo" can mean many things.

When you complete a new commit, Git will store a snapshot of the repository at the current moment in time; you can use Git to roll back the project to any previous version.

In the following, I will list several common scenarios that require "undo" and show you how to use Git to complete these operations.

Undo a "public" change

Scenario: You just pushed your local changes to GitHub using git push and you realize that you made a mistake in your commit. You want to undo this commit.

Use the undo command: git revert

What's happening: git revert will create a new commit with the inverse of the given SHA. If the old commit was "matter", then the new commit will be "anti-matter" - anything that was removed from the old commit will be added to the new commit, and anything that was added from the old commit will be removed from the new commit.

This is the safest and simplest "undo" scenario for Git, because it does not modify history - you can now git push the commit after the revert to correct the mistake.

2. Fix the last commit message

Scenario: You just made a typo in the final commit message, for example, you typed git commit -m "Fxies bug #42", and before executing git push you realized that you should have typed "Fixes bug #42".

Use the undo command: git commit –amend or git commit --amend -m "Fixes bug #42"

What happened: git commit --amend will update and replace the wrong commit with a new commit that contains all the changes that were just wrongly committed. Since there is no staged commit, this commit actually just rewrites the previous commit message.

Undo "local" changes

Scenario: When your cat crawls over the keyboard, the file you are editing is saved and your editor crashes. You have not committed any code at this time. You want to undo all changes in this file - roll back this file to the state of the last commit.

Use the undo command: git checkout --

What happens: git checkout modifies the files in the working directory to a state previously known to Git. You can provide a name or an exact SHA code of the branch you want to revert to, and Git will default to checking out HEAD, that is, the previous commit on the current branch.

Note: Changes that you "undo" in this way are truly gone. They will never be committed. Therefore, Git cannot recover them. At this point, be sure to know exactly what you are doing! (Perhaps you can use git diff to be sure)

4. Reset "local" changes

Scenario: You've made some commits locally (not pushed yet), but everything is screwed and you want to undo the last three commits - as if they never happened.

Use the undo command: git reset or git reset --hard

What's happening: git reset rewinds your repository all the way back to the last commit represented by the specified SHA, as if those commits never happened. By default, git reset preserves your working directory. The commits are gone, but the content is still on disk. This is the safest approach, but there are often cases where you want to "undo" all commits and local changes with one command - then use the --hard option.

5. Redo after undo "local"

Scenario: You’ve committed some stuff, undone those changes with git reset --hard (see above), and suddenly realize: you want to revert those changes!

Use the undo commands: git reflog and git reset, or git checkout

What happened: git reflog is a great way to recover your project's history. You can recover almost any commit with git reflog.

You may be familiar with the git log command, which displays a list of commits. git reflog is similar, except that it displays a list of how many times HEAD has changed.

Some notes:

1. Only HEAD changes. When you switch branches, commit changes with git commit, or undo commits with git reset, HEAD changes. But when you use git checkout --, HEAD does not change. (As mentioned above, those changes are not committed at all, so reflog cannot help us recover)

2. Git reflog will not exist forever. Git will periodically clean up those "unreachable" objects. Don't expect to find commit records from several months ago in the reflog.

3. The reflog is personal to you. You cannot use your reflog to restore commits that other developers have not pushed.

So, how to use reflog to retrieve the previous "unfinished" commits? It depends on what you want to do:

1. If you want to restore the project history to a certain commit, please use git reset --hard

2. If you want to restore one or more files in a commit in the working directory without changing the commit history, use git checkout --

3. If you want to roll back to a specific commit, use git cherry-pick.

Once more, with branching

Scenario: You commit some changes, then you realize you are on the master branch, but you expected to perform those commits on a feature branch.

Use the undo commands: git branch feature, git reset --hard origin/master, and git checkout feature

What happened: You probably used git checkout -b to create a new branch, which is a convenient way to create and check out a branch—but you don't actually want to switch branches right away. git branch feature will create a branch called feature that points to your most recent commit, but you'll still be on the master branch.

git reset --hard will revert master back to origin/master and ignore all new commits. Don't worry, those commits are still preserved on feature.

Finally, git checkout switches the branch to feature, which retains all your recent work intact.

7. Get twice the result with half the effort

Scenario: You created a new feature branch based on master, but the master branch is far behind origin/master. Now that the master branch is synchronized with origin/master, you hope to commit code immediately under feature at this time, and not when it is far behind master.

Use the undo command: git checkout feature and git rebase master

What happened: You could have typed git reset (without --hard, intentionally saving the commits on disk), then git checkout -b, and then re-committed your changes, but then you would have lost your local commits. However, there is a better way:

Using git rebase master you can do a few things:

1. First, it locates the common ancestor between your currently checked-out branch and master.

2. Then, it resets the currently checked-out branch to the ancestor node and temporarily stores all subsequent commits.

3. Finally, it pushes the current checked-out branch to the end of master, and resubmits the changes in the staging area after the last commit of master.

8. Mass undo/redo

Scenario: You start developing a feature towards a certain goal, but halfway through you decide that another approach is better. You already have a dozen commits, but you only want a few of them and can delete the rest.

Use the undo command: git rebase -i

What's happening: -i puts rebases into "interactive mode." The rebase starts out doing the same things as discussed above, but it pauses between commits and lets you modify each one.

rebase -i will open your default text editor and list the commits being performed, like this:

The first two columns are the most important: the first column is the selection 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 via the pick command.

To undo a commit, just delete the corresponding line in the editor. If you no longer need these wrong commits in your project, you can directly delete lines 1 and 3-4 in the figure above.

If you want to keep the commit but change the commit message, you can use the reword command. That is, replace the command keyword pick with reword (or r). You may want to change the commit message immediately, but doing so will not work - rebase -i will ignore everything after the SHA column. The existing commit message will help us remember what 0835fe2 stands for. After you type the rebase -i command, Git will start prompting you to rewrite the new commit message.

If you need to merge two commits, you can use the squash or fixup command, as shown below:

Both squash and fixup merge "upwards" - the commits that use these merge commands will be merged with the commits before them: above, 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; fixup will give you the commit message of the first commit in the list. In the figure above, af67f82 is an "Ooops" message because this commit message is already the same as 38f5e4e. But you can write a commit message for the new commit that merges 0835fe2 and 6943e85.

When you save and exit the editor, Git will apply your commits in order from top to bottom. You can change the order in which the commits are applied before saving them. If necessary, you can merge af67f82 and 0835fe2 and order them like this:

Fix an earlier commit

Scenario: You left a file in a previous commit, and it would be nice if the previous commit had what you left. You haven't pushed yet, and this commit isn't the most recent one, so you can't use commit --amend.

Use undo commands: git commit --squash and git rebase --autosquash -i

What happens: git commit --squash will create a new commit with a commit message that might look like this: "squash! Earlier commit." (You can also write this commit message by hand, commit --squash just saves you the typing.)

If you don't want to write a commit message for the merge, 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 message in the rebase.

rebase --autosquash –i will start the rebase interactive editor, which will list any completed squash! and fixup! commits, as shown below:

When using --squash and --fixup, you may not remember the SHA of the commit you want to fix—just know that it was one or five commits ago. You can probably use Git's ^ and ~ operators to manually retrieve it. HEAD^ means the commit before HEAD. HEAD~4 means the 4 commits before HEAD, which add up to the previous 5 commits.

10. Stop tracking a tracked file

Scenario: You accidentally added application.log to your repository, and now every time you run your program, Git complains that there are unstaged commits in application.log. You wrote "*.log" in .gitignore, but it still doesn't work - how do you tell Git to "undo" the changes to this file?

Use the undo command: git rm --cached application.log

What's happening: Although .gitignore prevents Git from tracking changes to a file, or even the existence of a previously untracked file, once the file is added or committed, Git will continue to track changes to the file. Similarly, if you use git add -f to "force" add, or override .gitignore, Git will continue to watch for changes. So it's best not to use -f to add .gitignore files in the future.

If you want to remove files that should be ignored, git rm --cached can help you and keep these files on disk. Because the 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 commands, you can move to the following related documents:

checkout

commit

rebase

reflog

reset

revert

rm