However, If you don’t need to reset to an earlier commit if you just made a mistake in your commit message. The easier option is to
git reset (to unstage any changes you’ve made since) and then
git commit --amend, which will open your default commit message editor pre-populated with the last commit message.
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.
Say you have this, where C is your HEAD and (F) is the state of your files.
You want to nuke commit C and never see it again. You do this:
git reset --hard HEAD~1
The result is:
Now B is the HEAD. Because you used
--hard, your files are reset to their state at commit B.
Ah, but suppose 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:
You can do this, leaving off the
git reset HEAD~1
In this case the result is:
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!
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.
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
git reflog and you’ll see a list of (partial) commit shas 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.
Another way of doing it can be following :
Add/remove files to get things the way you want:
git rm classdir
git add sourcedir
Then amend the commit:
git commit --amend
The previous, erroneous commit will be edited to reflect the new index state – in other words, it’ll be like you never made the mistake in the first place.
Note that you should only do this if you haven’t pushed yet. If you have pushed, then you’ll just have to commit a fix normally.
Yet Another approach can be :
This took me a while to figure out, so maybe this will help someone…
There are two ways to “undo” your last commit, depending on whether or not you have already made your commit public (pushed to your remote repository):
How to undo a local commit
Lets say I committed locally, but now want to remove that commit.
commit 101: bad commit # latest commit, this would be called 'HEAD'
commit 100: good commit # second to last commit, this is the one we want
To restore everything back to the way it was prior to the last commit, we need to
reset to the commit before
git reset --soft HEAD^ # use --soft if you want to keep your changes
git reset --hard HEAD^ # use --hard if you don't care about keeping the changes you made
git log will show that our last commit has been removed.
How to undo a public commit
If you have already made your commits public, you will want to create a new commit which will “revert” the changes you made in your previous commit (current HEAD).
git revert HEAD
Your changes will now be reverted and ready for you to commit:
git commit -m 'restoring the file I removed by accident'
commit 102: restoring the file I removed by accident
commit 101: removing a file we dont need
commit 100: adding a file that we need