Skip to main content
edited body
Source Link

Undoing a commit is a little scary if you don't know how it works. But it's actually amazingly easy if you do understand. I'll show you the 4 different ways you can undo a commit.

Say you have this, where C is your HEAD and (F) is the state of your files.

 (F) A-B-C ↑ master 

Option 1: git reset --hard

You want to destroy commit C and also throw away any uncommitted changes. You do this:

git reset --hard HEAD~1 

The result is:

 (F) A-B ↑ master 

Now B is the HEAD. Because you used --hard, your files are reset to their state at commit B.

Option 2: git reset

Maybe commit C wasn't a disaster, but just a bit off. You want to undo the commit but keep your changes for a bit of editing before you do a better commit. Starting again from here, with C as your HEAD:

 (F) A-B-C ↑ master 

Do this, leaving off the --hard:

git reset HEAD~1 

In this case the result is:

 (F) A-B-C ↑ master 

In both cases, HEAD is just a pointer to the latest commit. When you do a git reset HEAD~1, you tell Git to move the HEAD pointer back one commit. But (unless you use --hard) you leave your files as they were. So now git status shows the changes you had checked into C. You haven't lost a thing!

Option 3: git reset --soft

For the lightest touch, you can even undo your commit but leave your files and your index:

git reset --soft HEAD~1 

This not only leaves your files alone, it even leaves your index alone. When you do git status, you'll see that the same files are in the index as before. In fact, right after this command, you could do git commit and you'd be redoing the same commit you just had.

Option 4: you did git reset --hard and need to get that code back

One more thing: Suppose you destroy a commit as in the first example, but then discover you needed it after all? Tough luck, right?

Nope, there's still a way to get it back. Type this

git reflog 

and you'll see a list of (partial) commit shasSHAs (that is, hashes) that you've moved around in. Find the commit you destroyed, and do this:

git checkout -b someNewBranchName shaYouDestroyed 

You've now resurrected that commit. Commits don't actually get destroyed in Git for some 90 days, so you can usually go back and rescue one you didn't mean to get rid of.

Undoing a commit is a little scary if you don't know how it works. But it's actually amazingly easy if you do understand. I'll show you the 4 different ways you can undo a commit.

Say you have this, where C is your HEAD and (F) is the state of your files.

 (F) A-B-C ↑ master 

Option 1: git reset --hard

You want to destroy commit C and also throw away any uncommitted changes. You do this:

git reset --hard HEAD~1 

The result is:

 (F) A-B ↑ master 

Now B is the HEAD. Because you used --hard, your files are reset to their state at commit B.

Option 2: git reset

Maybe commit C wasn't a disaster, but just a bit off. You want to undo the commit but keep your changes for a bit of editing before you do a better commit. Starting again from here, with C as your HEAD:

 (F) A-B-C ↑ master 

Do this, leaving off the --hard:

git reset HEAD~1 

In this case the result is:

 (F) A-B-C ↑ master 

In both cases, HEAD is just a pointer to the latest commit. When you do a git reset HEAD~1, you tell Git to move the HEAD pointer back one commit. But (unless you use --hard) you leave your files as they were. So now git status shows the changes you had checked into C. You haven't lost a thing!

Option 3: git reset --soft

For the lightest touch, you can even undo your commit but leave your files and your index:

git reset --soft HEAD~1 

This not only leaves your files alone, it even leaves your index alone. When you do git status, you'll see that the same files are in the index as before. In fact, right after this command, you could do git commit and you'd be redoing the same commit you just had.

Option 4: you did git reset --hard and need to get that code back

One more thing: Suppose you destroy a commit as in the first example, but then discover you needed it after all? Tough luck, right?

Nope, there's still a way to get it back. Type this

git reflog 

and you'll see a list of (partial) commit shas (that is, hashes) that you've moved around in. Find the commit you destroyed, and do this:

git checkout -b someNewBranchName shaYouDestroyed 

You've now resurrected that commit. Commits don't actually get destroyed in Git for some 90 days, so you can usually go back and rescue one you didn't mean to get rid of.

Undoing a commit is a little scary if you don't know how it works. But it's actually amazingly easy if you do understand. I'll show you the 4 different ways you can undo a commit.

Say you have this, where C is your HEAD and (F) is the state of your files.

 (F) A-B-C ↑ master 

Option 1: git reset --hard

You want to destroy commit C and also throw away any uncommitted changes. You do this:

git reset --hard HEAD~1 

The result is:

 (F) A-B ↑ master 

Now B is the HEAD. Because you used --hard, your files are reset to their state at commit B.

Option 2: git reset

Maybe commit C wasn't a disaster, but just a bit off. You want to undo the commit but keep your changes for a bit of editing before you do a better commit. Starting again from here, with C as your HEAD:

 (F) A-B-C ↑ master 

Do this, leaving off the --hard:

git reset HEAD~1 

In this case the result is:

 (F) A-B-C ↑ master 

In both cases, HEAD is just a pointer to the latest commit. When you do a git reset HEAD~1, you tell Git to move the HEAD pointer back one commit. But (unless you use --hard) you leave your files as they were. So now git status shows the changes you had checked into C. You haven't lost a thing!

Option 3: git reset --soft

For the lightest touch, you can even undo your commit but leave your files and your index:

git reset --soft HEAD~1 

This not only leaves your files alone, it even leaves your index alone. When you do git status, you'll see that the same files are in the index as before. In fact, right after this command, you could do git commit and you'd be redoing the same commit you just had.

Option 4: you did git reset --hard and need to get that code back

One more thing: Suppose you destroy a commit as in the first example, but then discover you needed it after all? Tough luck, right?

Nope, there's still a way to get it back. Type this

git reflog 

and you'll see a list of (partial) commit SHAs (that is, hashes) that you've moved around in. Find the commit you destroyed, and do this:

git checkout -b someNewBranchName shaYouDestroyed 

You've now resurrected that commit. Commits don't actually get destroyed in Git for some 90 days, so you can usually go back and rescue one you didn't mean to get rid of.

Rollback to Revision 22
Source Link
Ryan Lundy
  • 211.3k
  • 41
  • 187
  • 216

Undoing a commit is a little scary if you don't know how it works. But it's actually amazingly easy if you do understand. I'll show you the 4 different ways you can undo a commit.

Say you have this, where C is your HEAD and (F) is the state of your files.

 (F) A-B-C ↑ master 

Option 1: git reset --hard

You want to destroy commit C and also throw away any uncommitted changes. You do this:

git reset --hard HEAD~1 

The result is:

 (F) A-B ↑ master 

Now B is the HEAD. Because you used --hard, your files are reset to their state at commit B.

Option 2: git reset

Maybe commit C wasn't a disaster, but just a bit off. You want to undo the commit but keep your changes for a bit of editing before you do a better commit. Starting again from here, with C as your HEAD:

 (F) A-B-C ↑ master 

Do this, leaving off the --hard:

git reset HEAD~1 

In this case, the result is:

 (F) A-B-C ↑ master 

In both cases, HEAD is just a pointer to the latest commit. When you do a git reset HEAD~1, you tell Git to move the HEAD pointer back one commit. But (unless you use --hard) you leave your files as they were. So now git status shows the changes you had checked into C. You haven't lost a thing!

Option 3: git reset --soft

For the lightest touch, you can even undo your commit but leave your files and your index:

git reset --soft HEAD~1 

This not only leaves your files alone, it even leaves your index alone. When you do git status, you'll see that the same files are in the index as before. In fact, right after this command, you could do git commit and you'd be redoing the same commit you just had.

Option 4: you did git reset --hard and need to get that code back

One more thing: Suppose you destroy a commit as in the first example, but then discover you needed it after all? Tough luck, right?

Nope, there's still a way to get it back. Type this

git reflog 

and you'll see a list of (partial) commit shas (that is, hashes) that you've moved around in. Find the commit you destroyed, and do this:

git checkout -b someNewBranchName shaYouDestroyed 

You've now resurrected that commit. Commits don't actually get destroyed in Git for some 90 days, so you can usually go back and rescue one you didn't mean to get rid of.

Undoing a commit is a little scary if you don't know how it works. But it's actually amazingly easy if you do understand. I'll show you the 4 different ways you can undo a commit.

Say you have this, where C is your HEAD and (F) is the state of your files.

 (F) A-B-C ↑ master 

Option 1: git reset --hard

You want to destroy commit C and also throw away any uncommitted changes. You do this:

git reset --hard HEAD~1 

The result is:

 (F) A-B ↑ master 

Now B is the HEAD. Because you used --hard, your files are reset to their state at commit B.

Option 2: git reset

Maybe commit C wasn't a disaster, but just a bit off. You want to undo the commit but keep your changes for a bit of editing before you do a better commit. Starting again from here, with C as your HEAD:

 (F) A-B-C ↑ master 

Do this, leaving off the --hard:

git reset HEAD~1 

In this case, the result is:

 (F) A-B-C ↑ master 

In both cases, HEAD is just a pointer to the latest commit. When you do a git reset HEAD~1, you tell Git to move the HEAD pointer back one commit. But (unless you use --hard) you leave your files as they were. So now git status shows the changes you had checked into C. You haven't lost a thing!

Option 3: git reset --soft

For the lightest touch, you can even undo your commit but leave your files and your index:

git reset --soft HEAD~1 

This not only leaves your files alone, it even leaves your index alone. When you do git status, you'll see that the same files are in the index as before. In fact, right after this command, you could do git commit and you'd be redoing the same commit you just had.

Option 4: you did git reset --hard and need to get that code back

One more thing: Suppose you destroy a commit as in the first example, but then discover you needed it after all? Tough luck, right?

Nope, there's still a way to get it back. Type this

git reflog 

and you'll see a list of (partial) commit shas (that is, hashes) that you've moved around in. Find the commit you destroyed, and do this:

git checkout -b someNewBranchName shaYouDestroyed 

You've now resurrected that commit. Commits don't actually get destroyed in Git for some 90 days, so you can usually go back and rescue one you didn't mean to get rid of.

Undoing a commit is a little scary if you don't know how it works. But it's actually amazingly easy if you do understand. I'll show you the 4 different ways you can undo a commit.

Say you have this, where C is your HEAD and (F) is the state of your files.

 (F) A-B-C ↑ master 

Option 1: git reset --hard

You want to destroy commit C and also throw away any uncommitted changes. You do this:

git reset --hard HEAD~1 

The result is:

 (F) A-B ↑ master 

Now B is the HEAD. Because you used --hard, your files are reset to their state at commit B.

Option 2: git reset

Maybe commit C wasn't a disaster, but just a bit off. You want to undo the commit but keep your changes for a bit of editing before you do a better commit. Starting again from here, with C as your HEAD:

 (F) A-B-C ↑ master 

Do this, leaving off the --hard:

git reset HEAD~1 

In this case the result is:

 (F) A-B-C ↑ master 

In both cases, HEAD is just a pointer to the latest commit. When you do a git reset HEAD~1, you tell Git to move the HEAD pointer back one commit. But (unless you use --hard) you leave your files as they were. So now git status shows the changes you had checked into C. You haven't lost a thing!

Option 3: git reset --soft

For the lightest touch, you can even undo your commit but leave your files and your index:

git reset --soft HEAD~1 

This not only leaves your files alone, it even leaves your index alone. When you do git status, you'll see that the same files are in the index as before. In fact, right after this command, you could do git commit and you'd be redoing the same commit you just had.

Option 4: you did git reset --hard and need to get that code back

One more thing: Suppose you destroy a commit as in the first example, but then discover you needed it after all? Tough luck, right?

Nope, there's still a way to get it back. Type this

git reflog 

and you'll see a list of (partial) commit shas (that is, hashes) that you've moved around in. Find the commit you destroyed, and do this:

git checkout -b someNewBranchName shaYouDestroyed 

You've now resurrected that commit. Commits don't actually get destroyed in Git for some 90 days, so you can usually go back and rescue one you didn't mean to get rid of.

added 1 character in body
Source Link
Nitin
  • 3k
  • 3
  • 39
  • 73

Undoing a commit is a little scary if you don't know how it works. But it's actually amazingly easy if you do understand. I'll show you the 4 different ways you can undo a commit.

Say you have this, where C is your HEAD and (F) is the state of your files.

 (F) A-B-C ↑ master 

Option 1: git reset --hard

You want to destroy commit C and also throw away any uncommitted changes. You do this:

git reset --hard HEAD~1 

The result is:

 (F) A-B ↑ master 

Now B is the HEAD. Because you used --hard, your files are reset to their state at commit B.

Option 2: git reset

Maybe commit C wasn't a disaster, but just a bit off. You want to undo the commit but keep your changes for a bit of editing before you do a better commit. Starting again from here, with C as your HEAD:

 (F) A-B-C ↑ master 

Do this, leaving off the --hard:

git reset HEAD~1 

In this case, the result is:

 (F) A-B-C ↑ master 

In both cases, HEAD is just a pointer to the latest commit. When you do a git reset HEAD~1, you tell Git to move the HEAD pointer back one commit. But (unless you use --hard) you leave your files as they were. So now git status shows the changes you had checked into C. You haven't lost a thing!

Option 3: git reset --soft

For the lightest touch, you can even undo your commit but leave your files and your index:

git reset --soft HEAD~1 

This not only leaves your files alone, it even leaves your index alone. When you do git status, you'll see that the same files are in the index as before. In fact, right after this command, you could do git commit and you'd be redoing the same commit you just had.

Option 4: you did git reset --hard and need to get that code back

One more thing: Suppose you destroy a commit as in the first example, but then discover you needed it after all? Tough luck, right?

Nope, there's still a way to get it back. Type this

git reflog 

and you'll see a list of (partial) commit shas (that is, hashes) that you've moved around in. Find the commit you destroyed, and do this:

git checkout -b someNewBranchName shaYouDestroyed 

You've now resurrected that commit. Commits don't actually get destroyed in Git for some 90 days, so you can usually go back and rescue one you didn't mean to get rid of.

Undoing a commit is a little scary if you don't know how it works. But it's actually amazingly easy if you do understand. I'll show you the 4 different ways you can undo a commit.

Say you have this, where C is your HEAD and (F) is the state of your files.

 (F) A-B-C ↑ master 

Option 1: git reset --hard

You want to destroy commit C and also throw away any uncommitted changes. You do this:

git reset --hard HEAD~1 

The result is:

 (F) A-B ↑ master 

Now B is the HEAD. Because you used --hard, your files are reset to their state at commit B.

Option 2: git reset

Maybe commit C wasn't a disaster, but just a bit off. You want to undo the commit but keep your changes for a bit of editing before you do a better commit. Starting again from here, with C as your HEAD:

 (F) A-B-C ↑ master 

Do this, leaving off the --hard:

git reset HEAD~1 

In this case the result is:

 (F) A-B-C ↑ master 

In both cases, HEAD is just a pointer to the latest commit. When you do a git reset HEAD~1, you tell Git to move the HEAD pointer back one commit. But (unless you use --hard) you leave your files as they were. So now git status shows the changes you had checked into C. You haven't lost a thing!

Option 3: git reset --soft

For the lightest touch, you can even undo your commit but leave your files and your index:

git reset --soft HEAD~1 

This not only leaves your files alone, it even leaves your index alone. When you do git status, you'll see that the same files are in the index as before. In fact, right after this command, you could do git commit and you'd be redoing the same commit you just had.

Option 4: you did git reset --hard and need to get that code back

One more thing: Suppose you destroy a commit as in the first example, but then discover you needed it after all? Tough luck, right?

Nope, there's still a way to get it back. Type this

git reflog 

and you'll see a list of (partial) commit shas (that is, hashes) that you've moved around in. Find the commit you destroyed, and do this:

git checkout -b someNewBranchName shaYouDestroyed 

You've now resurrected that commit. Commits don't actually get destroyed in Git for some 90 days, so you can usually go back and rescue one you didn't mean to get rid of.

Undoing a commit is a little scary if you don't know how it works. But it's actually amazingly easy if you do understand. I'll show you the 4 different ways you can undo a commit.

Say you have this, where C is your HEAD and (F) is the state of your files.

 (F) A-B-C ↑ master 

Option 1: git reset --hard

You want to destroy commit C and also throw away any uncommitted changes. You do this:

git reset --hard HEAD~1 

The result is:

 (F) A-B ↑ master 

Now B is the HEAD. Because you used --hard, your files are reset to their state at commit B.

Option 2: git reset

Maybe commit C wasn't a disaster, but just a bit off. You want to undo the commit but keep your changes for a bit of editing before you do a better commit. Starting again from here, with C as your HEAD:

 (F) A-B-C ↑ master 

Do this, leaving off the --hard:

git reset HEAD~1 

In this case, the result is:

 (F) A-B-C ↑ master 

In both cases, HEAD is just a pointer to the latest commit. When you do a git reset HEAD~1, you tell Git to move the HEAD pointer back one commit. But (unless you use --hard) you leave your files as they were. So now git status shows the changes you had checked into C. You haven't lost a thing!

Option 3: git reset --soft

For the lightest touch, you can even undo your commit but leave your files and your index:

git reset --soft HEAD~1 

This not only leaves your files alone, it even leaves your index alone. When you do git status, you'll see that the same files are in the index as before. In fact, right after this command, you could do git commit and you'd be redoing the same commit you just had.

Option 4: you did git reset --hard and need to get that code back

One more thing: Suppose you destroy a commit as in the first example, but then discover you needed it after all? Tough luck, right?

Nope, there's still a way to get it back. Type this

git reflog 

and you'll see a list of (partial) commit shas (that is, hashes) that you've moved around in. Find the commit you destroyed, and do this:

git checkout -b someNewBranchName shaYouDestroyed 

You've now resurrected that commit. Commits don't actually get destroyed in Git for some 90 days, so you can usually go back and rescue one you didn't mean to get rid of.

Rollback to Revision 20
Source Link
Ryan Lundy
  • 211.3k
  • 41
  • 187
  • 216
Loading
added 49 characters in body
Source Link
Chris Halcrow
  • 32.5k
  • 19
  • 202
  • 235
Loading
A bit of touch-up.
Source Link
Ryan Lundy
  • 211.3k
  • 41
  • 187
  • 216
Loading
Rollback to Revision 17
Source Link
Ryan Lundy
  • 211.3k
  • 41
  • 187
  • 216
Loading
Moved reset --hard as the second option. It is a good idea to start with a less brutal option.
Source Link
SKPS
  • 5.9k
  • 5
  • 38
  • 73
Loading
Rollback to Revision 15
Source Link
Ryan Lundy
  • 211.3k
  • 41
  • 187
  • 216
Loading
Dragon::Supervised edit (descriptions not implemented)
Source Link
Loading
this post is long (big wall of text). so i added some markdown sections to make the post easier for people to read and easier for people to skim.
Source Link
Trevor Boyd Smith
  • 19.5k
  • 37
  • 132
  • 193
Loading
Mention that `--hard` destroys locally modified files.
Source Link
Mikko Rantalainen
  • 16.4k
  • 11
  • 91
  • 132
Loading
Rollback to Revision 11
Source Link
Ryan Lundy
  • 211.3k
  • 41
  • 187
  • 216
Loading
Active reading.
Source Link
Peter Mortensen
  • 31.4k
  • 22
  • 110
  • 134
Loading
The term "shas" as a plural of "sha" seems to be constantly confusing people, so let's see if this helps.
Source Link
Ryan Lundy
  • 211.3k
  • 41
  • 187
  • 216
Loading
Rollback to Revision 8 - Edit approval overridden by post owner or moderator
Source Link
Ryan Lundy
  • 211.3k
  • 41
  • 187
  • 216
Loading
Rollback to Revision 5
Source Link
Ryan Lundy
  • 211.3k
  • 41
  • 187
  • 216
Loading
typo fix
Source Link
Alfe
  • 60.2k
  • 21
  • 117
  • 172
Loading
deleted 314 characters in body
Source Link
Ryan Lundy
  • 211.3k
  • 41
  • 187
  • 216
Loading
added 68 characters in body
Source Link
matanox
  • 13.9k
  • 22
  • 99
  • 181
Loading
Changed "resurrect commit" command to one line
Source Link
Ryan Lundy
  • 211.3k
  • 41
  • 187
  • 216
Loading
Added note on how to get back a destroyed commit
Source Link
Ryan Lundy
  • 211.3k
  • 41
  • 187
  • 216
Loading
Source Link
Ryan Lundy
  • 211.3k
  • 41
  • 187
  • 216
Loading