git reset --hard HEAD~1
git push -f <remote> <branch>
(Example push: git push -f origin bugfix/bug123)
This will undo the last commit and push the updated history to the remote. You need to pass the -f because you're replacing upstream history in the remote.
Edit:
Please note that --hard will make your commit unreachable (i.e. it will appear to be deleted, but you can still git show <hash> or git log <hash> it if you remember its hash). If you want to keep your changes, run:
git reset [--mixed] HEAD~1
At this point you have unstaged changes because you used --mixed, which is the default.
You may first want to update the remote tree first (i.e. remove the commit): git push -f <remote> <branch>
Since you still have your changes locally you can create another branch and commit them there (and push as you see fit).
git reset --hard HEAD~1
git push -f <remote> <branch>
(Example push: git push -f origin bugfix/bug123)
This will undo the last commit and push the updated history to the remote. You need to pass the -f because you're replacing upstream history in the remote.
Edit:
Please note that --hard will make your commit unreachable (i.e. it will appear to be deleted, but you can still git show <hash> or git log <hash> it if you remember its hash). If you want to keep your changes, run:
git reset [--mixed] HEAD~1
At this point you have unstaged changes because you used --mixed, which is the default.
You may first want to update the remote tree first (i.e. remove the commit): git push -f <remote> <branch>
Since you still have your changes locally you can create another branch and commit them there (and push as you see fit).
Generally, make an "inverse" commit, using:
git revert 364705c
then send it to the remote as usual:
git push
This won't delete the commit: it makes an additional commit that undoes whatever the first commit did. Anything else, not really safe, especially when the changes have already been propagated.
How to undo pushed commits
version control - How do I undo the most recent local commits in Git? - Stack Overflow
git - Remove last commit and push - Stack Overflow
Delete last Git commit from local and remote repositories.
-
One of our artists managed to push 1 month of progress without merging
-
As you can see I tried to undo the commits one by one in reverse order
-
I couldn't undo the merge commit of Arvincle because it's empty
-
When I try to revert the commit before that I get one file I need to merge first, but the rest of the changes are not undone
Is there a way to reset the HEAD of main to the last valid commit?
Undo a commit & redo
$ git commit -m "Something terribly misguided" # (0: Your Accident)
$ git reset HEAD~ # (1)
# === If you just want to undo the commit, stop here! ===
[ edit files as necessary ] # (2)
$ git add . # (3)
$ git commit -c ORIG_HEAD # (4)
git resetis the command responsible for the undo. It will undo your last commit while leaving your working tree (the state of your files on disk) untouched. You'll need to add them again before you can commit them again.- Make corrections to working tree files.
git addanything that you want to include in your new commit.- Commit the changes, reusing the old commit message.
resetcopied the old head to.git/ORIG_HEAD;commitwith-c ORIG_HEADwill open an editor, which initially contains the log message from the old commit and allows you to edit it. If you do not need to edit the message, you could use the-Coption.
Alternatively, to edit the previous commit (or just its commit message), commit --amend will add changes within the current index to the previous commit.
To remove (not revert) a commit that has been pushed to the server, rewriting history with git push origin main --force[-with-lease] is necessary. It's almost always a bad idea to use --force; prefer --force-with-lease instead, and as noted in the git manual:
You should understand the implications of rewriting history if you amend a commit that has already been published.
Further Reading
You can use git reflog to determine the SHA-1 for the commit to which you wish to revert. Once you have this value, use the sequence of commands as explained above.
HEAD~ is the same as HEAD~1. The article What is the HEAD in git? is helpful if you want to uncommit multiple commits.
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.
If you have already pushed this commit, then it is possible that someone else has pulled the branch. In this case, rewriting your branch's history is undesirable and you should instead revert this commit:
git revert <SHA-1>
git push origin branch
Here <SHA-1> is the commit hash of the commit you want to remove. To find this hash value, simply type git log on your branch and inspect the first entry.
Using git revert actually adds a new commit which is the mirror image of the commit you want to remove. It is the preferred way of undoing a commit on a public branch because it simply adds new information to the branch.
If you are certain that you are the only person using this branch, then you have another option:
git reset --hard HEAD~1
followed by
git push --force origin branch
But you should only use this option if no one else is sharing this branch.
The way I go about it is by typing git status, which allows us to verify the branch we're currently on, followed by:
git log
Then, you'll see something like this:
commit aa09a82fb69af2d1aebde51d71514f7a03c3a692
Author: User <user@useremail.com>
Date: Fri Nov 4 15:36:22 2016 -0400
Fix issue with vertical scroll being forced
commit 411771837efe3ed555395e77fd35105a500ab758
Author: User <user@useremail.com>
Date: Thu Nov 3 15:50:42 2016 -0400
Add user notifications
commit f43b262f4e02b5a7268280e1230d44e36d1e547b
Author: User <user@useremail.com>
Date: Thu Nov 3 12:11:00 2016 -0400
All your base are belong to us
So, this tells us that commit aa09a82f is your last one, and commit 41177183 is the one before it, then:
git reset --hard 41177183
...brings us back to that commit, retaining the remote backup. With another git status to make sure that everything is all set for the double push (I'm personally a bit obsessive compulsive about verifying my current branch, especially when multitasking):
git push origin :<branch_name>
git push origin <branch_name>
At this point, you should be all set, but it's always good to follow that up with:
git fetch --all --prune
git branch -av
...which cleans up your branch list and shows you both local and remote to compare the commit messages.
Also, if working with a team, make sure that they're aware of this before moving forward. You don't want them to pull or push the branch on their end before you remove the last commit and push.