How to revert commit git

How to revert a Git commit: A simple example

The git revert command is commonly misunderstood. In this quick tutorial, we will show you exactly how the command works and how to perform a simple undo in your repo.

The most misunderstood operation in the world of distributed version control must be the git revert command. Let’s walk through an example of how to revert a Git commit, and differentiate the git reset and git revert commands.

The purpose of the git revert command is to remove all the changes a single commit made to your source code repository. For example, if a past commit added a file named index.html to the repo, a git revert on that commit will remove the index.html file from the repo. If a past commit added a new line of code to a Java file, a git revert on that commit will remove the added line.

When you revert a Git commit, the changes from the targeted commit are removed from your local workspace. A new commit is also created to reflect the new state of your repository.

The syntax to revert a Git commit and undo unwanted changes is simple. All developers need to do is issue the git revert command and provide the ID of the commit to undo:

To really understand how to undo Git commits, look at this git revert example.

We will start with a git init command to create a completely clean repository:

With the repository initialized, we’ll add five files to the repo. Each time a new file is created, we add it to the Git index and create a new commit with a meaningful message.

A quick directory listing following the initial command batch shows five files in the current folder:

A call to the git reflog command will show us our current commit history:

What do you think would happen if we did a git revert on the third commit with ID 4945db2? This was the git commit that added the charlie.html file.

Will the git revert of commit 4945db2 remove delta.html and edison.html from the local workspace, but leave the other files alone?

Or will this git revert example leave four files in the local workspace and remove only the charlie.html file?

If you chose the last outcome, you’d be correct. Here’s why.

Developers also need to know that when they git revert a commit, the reverted commit is deleted from their local workspace, but not deleted from the local repository. The code associated with the reverted Git commit remains stored in the repository’s history of changes, which means reverted code is still referenceable if it ever needs to be accessed or reviewed in the future.

Options like continue, abort and edit help to simplify the process of how to git revert a commit.

In review, the steps to git revert a commit and undo unwanted changes are the following:

The git revert command is a simple way to remove a bug introduced to the version control system at some point in the past, or back out of a feature enhancement that wasn’t well-received by the client. If you want to undo changes that happened in a specific commit, the git revert command is the correct operation to choose.

How to revert initial git commit?

I commit to a git repository for the first time; I then regret the commit and want to revert it. I try

I get this message:

This commit is the first commit of the repository. Any idea how to undo git’s initial commit?

10 Answers 10

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

1 would remove added files for all other commits. Clearly the question is how to get to the same state as that command works in all other cases. See this gist for proof your solution doesn’t work gist.github.com/greggman/522fa69a21d6cfb3ff0b

You can delete the HEAD and restore your repository to a new state, where you can create a new initial commit:

After you create a new commit, if you have already pushed to remote, you will need to force it to the remote in order to overwrite the previous initial commit:

This question was linked from this blog post and an alternative solution was proposed for the newer versions of Git:

This solution assumes that:

Note: Moving or copying a git branch preserves its reflog (see this code) while deleting and then creating a new branch destroys it. Since you want to get back to the original state with no history you probably want to delete the branch, but others may want to consider this small note.

Under the conditions stipulated in the question:

If those preconditions are met, then the simplest way to undo the initial commit would be:

DANGER! This removes the Git repository directory.

It removes the Git repository directory permanently and irrecoverably, unless you’ve got backups somewhere. Under the preconditions, you’ve nothing you want to keep in the repository, so you’re not losing anything. All the files you added are still available in the working directories, assuming you have not modified them yet and have not deleted them, etc. However, doing this is safe only if you have nothing else in your repository at all. Under the circumstances described in the question ‘commit repository first time — then regret it’, it is safe. Very often, though, it is not safe.

It’s also safe to do this to remove an unwanted cloned repository; it does no damage to the repository that it was cloned from. It throws away anything you’ve done in your copy, but doesn’t affect the original repository otherwise.

Be careful, but it is safe and effective when the preconditions are met.

If you’ve done other things with your repository that you want preserved, then this is not the appropriate technique — your repository no longer meets the preconditions for this to be appropriate.

Git Revert

The git revert command can be considered an ‘undo’ type command, however, it is not a traditional undo operation. Instead of removing the commit from the project history, it figures out how to invert the changes introduced by the commit and appends a new commit with the resulting inverse content. This prevents Git from losing history, which is important for the integrity of your revision history and for reliable collaboration.

Reverting should be used when you want to apply the inverse of a commit from your project history. This can be useful, for example, if you’re tracking down a bug and find that it was introduced by a single commit. Instead of manually going in, fixing it, and committing a new snapshot, you can use git revert to automatically do all of this for you.

How it works

To demonstrate let’s create an example repo using the command line examples below:

Note that the 3rd commit is still in the project history after the revert. Instead of deleting it, git revert added a new commit to undo its changes. As a result, the 2nd and 4th commits represent the exact same code base and the 3rd commit is still in our history just in case we want to go back to it down the road.

Common options

This is a default option and doesn’t need to be specified. This option will open the configured system editor and prompts you to edit the commit message prior to committing the revert

Passing this option will prevent git revert from creating a new commit that inverses the target commit. Instead of creating the new commit this option will add the inverse changes to the Staging Index and Working Directory. These are the other trees Git uses to manage the state of the repository. For more info visit the git reset page.

Resetting vs. reverting

It’s important to understand that git revert undoes a single commit—it does not «revert» back to the previous state of a project by removing all subsequent commits. In Git, this is actually called a reset, not a revert.

Reverting has two important advantages over resetting. First, it doesn’t change the project history, which makes it a “safe” operation for commits that have already been published to a shared repository. For details about why altering shared history is dangerous, please see the git reset page.

Summary

How to revert commit git

Given one or more existing commits, revert the changes that the related patches introduce, and record some new commits that record them. This requires your working tree to be clean (no modifications from the HEAD commit).

OPTIONS

With this option, git revert will let you edit the commit message prior to committing the revert. This is the default if you run the command from a terminal.

Usually you cannot revert a merge because you do not know which side of the merge should be considered the mainline. This option specifies the parent number (starting from 1) of the mainline and allows revert to reverse the change relative to the specified parent.

Reverting a merge commit declares that you will never want the tree changes brought in by the merge. As a result, later merges will only bring in tree changes introduced by commits that are not ancestors of the previously reverted merge. This may or may not be what you want.

With this option, git revert will not start the commit message editor.

Usually the command automatically creates some commits with commit log messages stating which commits were reverted. This flag applies the changes necessary to revert the named commits to your working tree and the index, but does not make the commits. In addition, when this option is used, your index does not have to match the HEAD commit. The revert is done against the beginning state of your index.

This is useful when reverting more than one commits’ effect to your index in a row.

GPG-sign commits. The keyid argument is optional and defaults to the committer identity; if specified, it must be stuck to the option without a space.

Add Signed-off-by line at the end of the commit message. See the signoff option in git-commit[1] for more information.

Use the given merge strategy. Should only be used once. See the MERGE STRATEGIES section in git-merge[1] for details.

Pass the merge strategy-specific option through to the merge strategy. See git-merge[1] for details.

Allow the rerere mechanism to update the index with the result of auto-conflict resolution if possible.

SEQUENCER SUBCOMMANDS

Forget about the current operation in progress. Can be used to clear the sequencer state after a failed cherry-pick or revert.

Cancel the operation and return to the pre-sequence state.

EXAMPLES

Revert the changes specified by the fourth last commit in HEAD and create a new commit with the reverted changes.

Revert the changes done by commits from the fifth last commit in master (included) to the third last commit in master (included), but do not create any commit with the reverted changes. The revert only modifies the working tree and the index.

How do I reverse a commit in git?

I’m not really familiar with how git works. I pushed a commit by mistake and want to revert it. I did a

Beware Fellow Googlers: This does not only revert the commit, but discards all file changes!

and now the project is reverted on my machine, but not on github. If I try to push this code, I get the error ‘Your branch is behind ‘origin/master’ by 1 commit, and can be fast-forwarded.’ How do I remove this commit from github?

6 Answers 6

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

This article has an excellent explanation as to how to go about various scenarios (where a commit has been done as well as the push OR just a commit, before the push):

From the article, the easiest command I saw to revert a previous commit by its commit id, was:

If you want to prevent this problem, don’t use reset, but instead use git revert

Or you can try using git revert http://www.kernel.org/pub/software/scm/git/docs/git-revert.html. I think something like git revert HEAD

Unable to comment on others answers, I’ll provide a bit of extra information.

The reason you use head

reset is to a commit, revert is on a commit.

As AmpT pointed out, you can also use the commit SHA to identify it, rather than counting how far away from head it is. The SHA can be found in the logs ( git log ) and a variety of other ways.