How to back to commit

Using Git — how to go back to a previous commit

Git & GitHub are powerful tools which allow us to track all our changes to our projects and, when we inevitably do something that breaks them, go back to a previous working state. We are all aware of this time-reversing magic, but not necessarily how to do it!

Here’s a quick and simple guide on how to turn back time on your project and revert to a previous version.

Find the version you want to go back to

You have two options here:

1) In your terminal you can type:

2) You can go through your commit history on your GitHub repo via the GitHub website. This allows you to check the state of all the files in the repo at each commit to make sure you are going back to the correct version.

This is useful if you didn’t give yourself useful commit messages, or you’re just not sure exactly which version you need to go back to. Committing little and often, so that your change history is clear should save you from having to take this route.

Whichever option you use, take a note of the ID of the commit you want to revert to.

Go back to the selected commit on your local environment

Use git checkout & the ID (in the same way you would checkout a branch) to go back:

This will take you to the version you wanted to go back to in your local environment.

Add this version to the staging area and push to remote

In the same way that you would with any normal commit, you have to add all files and push to remote to save this state.

Give yourself a slightly more descriptive commit message — maybe why you are reverting!!

And that’s it! You’ve turned back time on your project! Hurrah!

How to get back to the latest commit after checking out a previous commit?

11 Answers 11

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

If you know the commit you want to return to is the head of some branch, or is tagged, then you can just

You can also use git reflog to see what other commits your HEAD (or any other ref) has pointed to in the past.

In newer versions of Git, if you only ran git checkout or something else to move your HEAD once, you can also do

git checkout master

master is the tip, or the last commit. gitk will only show you up to where you are in the tree at the time. git reflog will show all the commits, but in this case, you just want the tip, so git checkout master.

Came across this question just now and have something to add

To go to the most recent commit:

Explanation:

Note:

To go to the branch of the most recent commit:

Explanation:

*) HEAD and remote branches are listed first, local branches are listed last in alphabetically descending order, so the one remaining will be the alphabetically first branch name

Note:

This will always only use the (alphabetically) first branch name if there are multiple for that commit.

Anyway, I think the best solution would just be to display the ref names for the most recent commit to know where to checkout to:

How to reset, revert, and return to previous states in Git

One of the lesser understood (and appreciated) aspects of working with Git is how easy it is to get back to where you were before—that is, how easy it is to undo even major changes in a repository. In this article, we’ll take a quick look at how to reset, revert, and completely return to previous states, all with the simplicity and elegance of individual Git commands.

How to reset a Git commit

Take a look at Figure 1. Here we have a representation of a series of commits in Git. A branch in Git is simply a named, movable pointer to a specific commit. In this case, our branch master is a pointer to the latest commit in the chain.

Fig. 1: Local Git environment with repository, staging area, and working directory

If we look at what’s in our master branch now, we can see the chain of commits made so far.

Programming and development

What happens if we want to roll back to a previous commit. Simple—we can just move the branch pointer. Git supplies the reset command to do this for us. For example, if we want to reset master to point to the commit two back from the current commit, we could use either of the following methods:

$ git reset 9ef9173 (using an absolute commit SHA1 value 9ef9173)

$ git reset current

Figure 2 shows the results of this operation. After this, if we execute a git log command on the current branch (master), we’ll see just the one commit.

Fig. 2: After reset

The git reset command also includes options to update the other parts of your local environment with the contents of the commit where you end up. These options include: hard to reset the commit being pointed to in the repository, populate the working directory with the contents of the commit, and reset the staging area; soft to only reset the pointer in the repository; and mixed (the default) to reset the pointer and the staging area.

How to revert a Git commit

The net effect of the git revert command is similar to reset, but its approach is different. Where the reset command moves the branch pointer back in the chain (typically) to «undo» changes, the revert command adds a new commit at the end of the chain to «cancel» changes. The effect is most easily seen by looking at Figure 1 again. If we add a line to a file in each commit in the chain, one way to get back to the version with only two lines is to reset to that commit, i.e., git reset HEAD

Another way to end up with the two-line version is to add a new commit that has the third line removed—effectively canceling out that change. This can be done with a git revert command, such as:

Because this adds a new commit, Git will prompt for the commit message:

Figure 3 (below) shows the result after the revert operation is completed.

If we do a git log now, we’ll see a new commit that reflects the contents before the previous commit.

Here are the current contents of the file in the working directory:

Revert or reset?

Why would you choose to do a revert over a reset operation? If you have already pushed your chain of commits to the remote repository (where others may have pulled your code and started working with it), a revert is a nicer way to cancel out changes for them. This is because the Git workflow works well for picking up additional commits at the end of a branch, but it can be challenging if a set of commits is no longer seen in the chain when someone resets the branch pointer back.

This brings us to one of the fundamental rules when working with Git in this manner: Making these kinds of changes in your local repository to code you haven’t pushed yet is fine. But avoid making changes that rewrite history if the commits have already been pushed to the remote repository and others may be working with them.

In short, if you rollback, undo, or rewrite the history of a commit chain that others are working with, your colleagues may have a lot more work when they try to merge in changes based on the original chain they pulled. If you must make changes against code that has already been pushed and is being used by others, consider communicating before you make the changes and give people the chance to merge their changes first. Then they can pull a fresh copy after the infringing operation without needing to merge.

You may have noticed that the original chain of commits was still there after we did the reset. We moved the pointer and reset the code back to a previous commit, but it did not delete any commits. This means that, as long as we know the original commit we were pointing to, we can «restore» back to the previous point by simply resetting back to the original head of the branch:

A similar thing happens in most other operations we do in Git when commits are replaced. New commits are created, and the appropriate pointer is moved to the new chain. But the old chain of commits still exists.

Rebase

Fig. 4: Chain of commits for branches master and feature

If we look at the log of commits in the branches, they might look like the following. (The C designators for the commit messages are used to make this easier to understand.)

I tell people to think of a rebase as a «merge with history» in Git. Essentially what Git does is take each different commit in one branch and attempt to «replay» the differences onto the other branch.

So, we can rebase a feature onto master to pick up C4 (e.g., insert it into feature’s chain). Using the basic Git commands, it might look like this:

Afterward, our chain of commits would look like Figure 5.

Fig. 5: Chain of commits after the rebase command

Again, looking at the log of commits, we can see the changes.

Notice that we have C3′ and C5′ —new commits created as a result of making the changes from the originals «on top of» the existing chain in master. But also notice that the «original» C3 and C5 are still there—they just don’t have a branch pointing to them anymore.

If we did this rebase, then decided we didn’t like the results and wanted to undo it, it would be as simple as:

With this simple change, our branch would now point back to the same set of commits as before the rebase operation—effectively undoing it (Figure 6).

Fig. 6: After undoing the rebase operation

We could use the reset command, as before, to point back to the original chain. Then the log would show this:

Another place to get this information is in the reflog. The reflog is a play-by-play listing of switches or changes to references in your local repository. To see it, you can use the git reflog command:

You can then reset to any of the items in that list using the special relative naming format you see in the log:

Once you understand that Git keeps the original chain of commits around when operations «modify» the chain, making changes in Git becomes much less scary. This is one of Git’s core strengths: being able to quickly and easily try things out and undo them if they don’t work.

Brent Laster will present Power Git: Rerere, Bisect, Subtrees, Filter Branch, Worktrees, Submodules, and More at the 20th annual OSCON event, July 16-19 in Portland, Ore. For more tips and explanations about using Git at any level, checkout Brent’s book «Professional Git,» available on Amazon.

Rollback to an old Git commit in a public repo

How can I go about rolling back to a specific commit in git?

The best answer someone could give me was to use git revert X times until I reach the desired commit.

So let’s say I want to revert back to a commit that’s 20 commits old, I’d have to run it 20 times.

Is there an easier way to do this?

I can’t use reset because this repository is public.

11 Answers 11

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

where [revision] is the commit hash (for example: 12345678901234567890123456789012345678ab ).

You can undo this by

that will delete all modifications from the working directory and staging area.

To rollback to a specific commit:

To rollback 10 commits back:

You can use «git revert» as in the following post if you don’t want to rewrite the history

Well, I guess the question is, what do you mean by ‘roll back’? If you can’t reset because it’s public and you want to keep the commit history intact, do you mean you just want your working copy to reflect a specific commit? Use git checkout and the commit hash.

The original poster states:

The best answer someone could give me was to use git revert X times until I reach the desired commit.

So let’s say I want to revert back to a commit that’s 20 commits old, I’d have to run it 20 times.

Is there an easier way to do this?

I can’t use reset cause this repo is public.

It’s not necessary to use git revert X times. git revert can accept a commit range as an argument, so you only need to use it once to revert a range of commits. For example, if you want to revert the last 20 commits:

The commit range HEAD

20.. is short for HEAD

That will revert that last 20 commits, assuming that none of those are merge commits. If there are merge commits, then you cannot revert them all in one command, you’ll need to revert them individually with

Note also that I’ve tested using a range with git revert using git version 1.9.0. If you’re using an older version of git, using a range with git revert may or may not work.

How to rollback everything to previous commit

Recently in a project with multiple people, a commit was made as seen in the image below. Marked in red you can see a commit with the description/comment of ‘Merge?’.

This commit added numerous files and altered numerous others and was never intended to take place.

Using atlassian-sourcetree what do I need to do to roll everything back to the commit highlighted in blue? (I am 8 commits behind as seen in the screenshot.)

3 Answers 3

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

If you have pushed the commits upstream.

If you have not pushed the commits upstream.

I searched for multiple options to get my git reset to specific commit, but most of them aren’t so satisfactory.

I generally use this to reset the git to the specific commit in source tree.

select commit to reset on sourcetree.

And right click on «Reset branch to this commit» and select hard reset option (soft, mixed and hard)

You should be all set!

There are two options to revert one commit our merged branch.

A. Using sourcetree

B. Using terminal

Select your commit and look info on bottom side of screen. Example commit id: 1a6cd9879d8c7d98cdcd9da9cac8979dac7a89c

Click top right corner «Terminal» option of Sourcetree.

When the commit message editor opens up: