How do I revert a Git repository to a previous commit?
Asked Answered
A

41

7611

How do I revert from my current state to a snapshot made on a certain commit?

If I do git log, then I get the following output:

$ git log
commit a867b4af366350be2e7c21b8de9cc6504678a61b`
Author: Me <[email protected]>
Date:   Thu Nov 4 18:59:41 2010 -0400

blah blah blah...

commit 25eee4caef46ae64aa08e8ab3f988bc917ee1ce4
Author: Me <[email protected]>
Date:   Thu Nov 4 05:13:39 2010 -0400

more blah blah blah...

commit 0766c053c0ea2035e90f504928f8df3c9363b8bd
Author: Me <[email protected]>
Date:   Thu Nov 4 00:55:06 2010 -0400

And yet more blah blah...

commit 0d1d7fc32e5a947fbd92ee598033d85bfc445a50
Author: Me <[email protected]>
Date:   Wed Nov 3 23:56:08 2010 -0400

Yep, more blah blah.

How do I revert to the commit from November 3, i.e. commit 0d1d7fc?

Aquitaine answered 6/11, 2010 at 16:58 Comment(3)
Related How to undo the last Git commit?.Expire
Here's a very clear and thorough post about undoing things in git, straight from Github.Weakling
I love git, but the fact that there's 35 answers to something that should be incredibly simple exposes a huge issue with git. Or is it the docs?Irritated
T
12241

This depends a lot on what you mean by "revert".

Temporarily switch to a different commit

If you want to temporarily go back to it, fool around, then come back to where you are, all you have to do is check out the desired commit:

# This will detach your HEAD, that is, leave you with no branch checked out:
git checkout 0d1d7fc32

Or if you want to make commits while you're there, go ahead and make a new branch while you're at it:

git checkout -b old-state 0d1d7fc32

To go back to where you were, just check out the branch you were on again. (If you've made changes, as always when switching branches, you'll have to deal with them as appropriate. You could reset to throw them away; you could stash, checkout, stash pop to take them with you; you could commit them to a branch there if you want a branch there.)

Hard delete unpublished commits

If, on the other hand, you want to really get rid of everything you've done since then, there are two possibilities. One, if you haven't published any of these commits, simply reset:

# This will destroy any local modifications.
# Don't do it if you have uncommitted work you want to keep.
git reset --hard 0d1d7fc32

# Alternatively, if there's work to keep:
git stash
git reset --hard 0d1d7fc32
git stash pop
# This saves the modifications, then reapplies that patch after resetting.
# You could get merge conflicts, if you've modified things which were
# changed since the commit you reset to.

If you mess up, you've already thrown away your local changes, but you can at least get back to where you were before by resetting again.

Undo published commits with new commits

On the other hand, if you've published the work, you probably don't want to reset the branch, since that's effectively rewriting history. In that case, you could indeed revert the commits. In many enterprise organisations, the concept of "protected" branches will even prevent history from being rewritten on some major branches. In this case, reverting is your only option.

With Git, revert has a very specific meaning: create a commit with the reverse patch to cancel it out. This way you don't rewrite any history.

First figure out what commits to revert. Depending on the technique chosen below, you want to either revert only the merge commits, or only the non-merge commits.

# This lists all merge commits between 0d1d7fc and HEAD:
git log --merges --pretty=format:"%h" 0d1d7fc..HEAD | tr '\n' ' '

# This lists all non merge commits between 0d1d7fc and HEAD:
git log --no-merges --pretty=format:"%h" 0d1d7fc..HEAD | tr '\n' ' '

Note: if you revert multiple commits, the order matters. Start with the most recent commit.

# This will create three separate revert commits, use non merge commits only:
git revert a867b4af 25eee4ca 0766c053

# It also takes ranges. This will revert the last two commits:
git revert HEAD~2..HEAD

# Similarly, you can revert a range of commits using commit hashes (non inclusive of first hash):
git revert 0d1d7fc..a867b4a

# Reverting a merge commit. You can also use a range of merge commits here.
git revert -m 1 <merge_commit_sha>

# To get just one, you could use `rebase -i` to squash them afterwards
# Or, you could do it manually (be sure to do this at top level of the repo)
# get your index and work tree into the desired state, without changing HEAD:
git checkout 0d1d7fc32 .

# Then commit. Be sure and write a good message describing what you just did
git commit

The git-revert manpage actually covers a lot of this in its description. Another useful link is this git-scm.com section discussing git-revert.

If you decide you didn't want to revert after all, you can revert the revert (as described here) or reset back to before the revert (see the previous section).

You may also find this answer helpful in this case:
How can I move HEAD back to a previous location? (Detached head) & Undo commits

Tavy answered 6/11, 2010 at 17:4 Comment(15)
@Rod's comment on git revert HEAD~3 as the best wat to revert back 3 commits is am important convention.Organist
Could you write the whole number? like: git reset --hard 0d1d7fc32e5a947fbd92ee598033d85bfc445a50Raddi
@MathiasMadsenStav Yes, you can of course specify commits by the full SHA1. I used abbreviated hashes to make the answer more readable, and you also tend to use them if you're typing out. If you're copying and pasting, by all means use the full hash. See Specifying Revisions in man git rev-parse for a full description of how you can name commits.Tavy
You can use git revert --no-commit hash1 hash2 ... and after this just commit every single revert in one commit git commit -m "Message"Dorinda
@cascabel git revert -m <number> <full SHA1> worked fine for me! I prefer this over git revert <commit SHA1>Civilized
git revert is not all that innocent. It has it's issues as well: #44266707Illconsidered
What is the 1 in -m?Neuroma
git checkout <hash> ., git commit -m "Revert to <hash>", git pushPosh
Great answer @Cascabel, git reset --hard git_sha worked for my case, but it annoys me that I cannot hit Tab and get auto-completion, it's cumbersome to write the whole sha e.g. 0d1d7fc32Scrofula
I wish the world had settled on Mercurial instead of Git. It's way too easy to break things with Git and I'm scared to use it in its CLI form :( TortoiseHg is also vastly better than any Git interface I've found. Sigh.Tint
What I did is only git revert -m 1 {bad-commit} && git commitValidity
As this post is locked, i'll leave my contribution with a git revert script that's generate a unique commit with the rollback code here: github.com/alexandrehpiva/git-revert-scriptRichard
If the master branch needs a Pull Request to accept changes (e.g. git flow and you can't git push force your changes), you can replace the commit's files with an older commit's files: https://mcmap.net/q/12444/-how-to-rollback-everything-to-previous-commitKahaleel
Use git checkout main to undo git checkout 0d1d7fc32.Constantia
Souldn't there be a git clean -f -d to remove new files and directories since the commit? At least, mention to consider it?Breathing
K
3642

Lots of complicated and dangerous answers here, but it's actually easy:

git revert --no-commit 0d1d7fc3..HEAD
git commit

This will revert everything from the HEAD back to the commit hash (excluded), meaning it will recreate that commit state in the working tree as if every commit after 0d1d7fc3 had been walked back. You can then commit the current tree, and it will create a brand new commit essentially equivalent to the commit you "reverted" to.

(The --no-commit flag lets git revert all the commits at once- otherwise you'll be prompted for a message for each commit in the range, littering your history with unnecessary new commits.)

This is a safe and easy way to rollback to a previous state. No history is destroyed, so it can be used for commits that have already been made public.


Note on merge commits:
If one of the commits between 0766c053..HEAD (inclusive) is a merge then there will be an error popping up (to do with no -m specified). The following link may help those encountering that: Why does git revert complain about a missing -m option? (thanks @timhc22 for pointing out)

Kynewulf answered 12/2, 2014 at 4:18 Comment(12)
If you really do want to have individual commits (instead of reverting everything with one big commit), then you can pass --no-edit instead of --no-commit, so that you don't have to edit a commit message for each reversion.Expire
$ git revert --no-commit 53742ae..HEAD returns fatal: empty commit set passedWow
If you remove that '..HEAD' at the end of the command, you can remove only a specific commit. For example: git revert --no-commit 0766c053 will remove only the specific changes made for 0766c053 keeping all changes after 0766c053 untouched.Copyreader
As @timhc22 mentioned, this doesn't work if there is one or more merge commits in between (which can happen frequently). An answer that really works in all cases and is just as safe is here: https://mcmap.net/q/12150/-revert-to-a-commit-by-a-sha-hash-in-git-duplicateBourbon
Note that if you want to revert to the previous commit without the commit ID you can use git revert --no-commit HEAD~1..HEAD and if you want to revert the last 5 commits you can do git revert --no-commit HEAD~5..HEADPlasmodium
It's interesting how wrong everything else is.. This seems like such a simple thing to do (eg I want to put it back to this, with a commit to share).Gillett
For me, reverting left a bunch of different files. What worked for me was this answer by user VonC. git restore -s <SHA1> -- . git-restore docs: git-scm.com/docs/git-restore -s - source -- - do not interpret any more arguments as options . - path (in my case, the repository root, recursively)Alate
It won't work if some of the commits are merges from other branches. Any solution for this specific case?Fahland
It's by far the best and the safest approach which worked to me as a chime, thanks!Legault
"as if every commit after 0766c053 had been walked back" Shouldn't this be every commit after 0d1d7fc? Op wants to return to 0d1d7fc, and walk back every commit after 0766c053 and including 0766c053. Answer is correct, just confused about the wording or don't have reading comprehension.Moonlit
Thank you, this is safest method if you want to revert back to a previous commit in branch.Dougald
@ParanoidAltoid Exactly what I've found out, the command should be git revert --no-commit 0d1d7fc32e5a947fbd92ee598033d85bfc445a50..HEAD and not what the answer was (I'm going to edit that because that's just plainly confusing).Kwangchowan
A
2107

Rogue Coder?

Working on your own and just want it to work? Follow these instructions below, they’ve worked reliably for me and many others for years.

Working with others? Git is complicated. Read the comments below this answer, consider other answers, and discuss with your team before you do something rash.

Reverting Working Copy to Most Recent Commit

To revert to the previous commit, ignoring any changes:

git reset --hard HEAD

where HEAD is the last commit in your current branch

Reverting The Working Copy to an Older Commit

To revert to a commit that's older than the most recent commit:

# Resets index to former commit; replace '56e05fced' with your commit code
git reset 56e05fced 

# Moves pointer back to previous HEAD
git reset --soft HEAD@{1}

git commit -m "Revert to 56e05fced"

# Updates working copy to reflect the new commit
git reset --hard

# Push your changes to respective branch
git push -f

Credits go to a similar Stack Overflow question, Revert to a commit by a SHA hash in Git?.

Antimalarial answered 21/8, 2012 at 6:19 Comment(9)
I did that, but then I wasn't able to commit and push to the remote repository. I want a specific older commit to become HEAD...Amazonite
@Lennon. Say you made a change, committed, and pushed it. You want both local and remote to appear as though this never happened. First git reset --hard HEAD^ You've now blown away all local changes from the last commit. Then: git push --force origin HEAD This takes the current HEAD commit in local and overwrites the HEAD in the remote, removing the last commit. Note: This isn't a secure way to delete secrets accidentally pushed to a remote. Assume all secrets are compromised then See caveats for '--force': evilmartians.com/chronicles/…Varnado
After reseting you need to do git push -f. Be VERY careful because it will erase the commits in front of the one you reset to from your remote branch!Jinny
"git revert [COMMIT HASH] --no-edit" this will do it without needing to make a commit message... much easierHypophyge
OP asks for revert. Guy gives answer with resetNaldo
the best of all time in the whole wide worldPlow
@Naldo "git revert should be used to undo changes on a public branch, and git reset should be reserved for undoing changes on a private branch. You can also think of git revert as a tool for undoing committed changes, while git reset HEAD is for undoing uncommitted changes."Antimalarial
@Antimalarial my statement stands. Here is the revert answer: https://mcmap.net/q/11819/-how-do-i-revert-a-git-repository-to-a-previous-commitNaldo
Note if you do a git reset --hard HEAD, new untracked files and directories will be left behind. You can clean those up with git clean -f -d as detailed here.Antilog
G
351

The best option for me and probably others is the Git reset option:

git reset --hard <commitId> && git clean -f

This has been the best option for me! It is simple, fast and effective!


** Note:** As mentioned in comments don't do this if you're sharing your branch with other people who have copies of the old commits

Also from the comments, if you wanted a less 'ballzy' method you could use

git clean -i

NOTE : This is getting a lot of attention. It's super important you do not do this if you're working on a branch which other people working from, also (depending on time frame) not one remote which has been merged with master. You will run into git hell.

Gershwin answered 22/10, 2013 at 11:53 Comment(4)
Obligatory Warning: don't do this if you're sharing your branch with other people who have copies of the old commits, because using a hard reset like this will force them to have to resynchronize their work with the newly reset branch. For a solution that explains in detail how to safely revert commits without losing work with a hard reset, see this answer.Expire
It's worth noting this will permanently delete any uncommitted files in your source directory :/Meiny
is it necessary for the git clean -i ?Backbreaking
I find git reset --hard <commitId> && git clean -f -d more useful since adding the -f -d flag deletes new directories and files within them as oppossed to just -f flag which only deletes new files.Disciple
H
310

Before answering let's add some background, explaining what this HEAD is.

First of all what is HEAD?

HEAD is simply a reference to the current commit (latest) on the current branch. There can only be a single HEAD at any given time (excluding git worktree).

The content of HEAD is stored inside .git/HEAD, and it contains the 40-bytes SHA-1 hash of the current commit.


detached HEAD

If you are not on the latest commit - meaning that HEAD is pointing to a prior commit in history it's called detached HEAD.

Diagram illustrating the concept of detached HEAD

On the command-line it will look like this - SHA-1 hash instead of the branch name since the HEAD is not pointing to the the tip of the current branch:

Running git checkout HEAD^0 in a terminal


A few options on how to recover from a detached HEAD:


git checkout

git checkout <commit_id>
git checkout -b <new branch> <commit_id>
git checkout HEAD~X // x is the number of commits t go back

This will checkout new branch pointing to the desired commit. This command will checkout to a given commit.

At this point you can create a branch and start to work from this point on:

# Checkout a given commit.
# Doing so will result in a `detached HEAD` which mean that the `HEAD`
# is not pointing to the latest so you will need to checkout branch
# in order to be able to update the code.
git checkout <commit-id>

# Create a new branch forked to the given commit
git checkout -b <branch name>

git reflog

You can always use the reflog as well. git reflog will display any change which updated the HEAD and checking out the desired reflog entry will set the HEAD back to this commit.

Every time the HEAD is modified there will be a new entry in the reflog

git reflog
git checkout HEAD@{...}

This will get you back to your desired commit.

Running git reflog in a terminal


git reset HEAD --hard <commit_id>

"Move" your HEAD back to the desired commit.

# This will destroy any local modifications.
# Don't do it if you have uncommitted work you want to keep.
git reset --hard 0d1d7fc32

# Alternatively, if there's work to keep:
git stash
git reset --hard 0d1d7fc32
git stash pop
# This saves the modifications, then reapplies that patch after resetting.
# You could get merge conflicts, if you've modified things which were
# changed since the commit you reset to.
  • Note: (Since Git 2.7) you can also use the git rebase --no-autostash as well.

This schema illustrates which command does what. As you can see there reset && checkout modify the HEAD.

Diagram illustrating staging area and checking out HEAD

Houseyhousey answered 5/2, 2015 at 21:56 Comment(1)
Shouldn't this diagrams show that git reset may modify the working tree (git reset --hard)?Breathing
B
226

You can do this by the following two commands:

git reset --hard [previous Commit SHA id here]
git push origin [branch Name] -f

It will remove your previous Git commit.

If you want to keep your changes, you can also use:

git reset --soft [previous Commit SHA id here]

Then it will save your changes.

Belva answered 12/12, 2014 at 6:52 Comment(1)
This one worked perfectly for me. Thx kiranSha
R
225

If you want to "uncommit", erase the last commit message, and put the modified files back in staging, you would use the command:

git reset --soft HEAD~1
  • --soft indicates that the uncommitted files should be retained as working files opposed to --hard which would discard them.
  • HEAD~1 is the last commit. If you want to rollback 3 commits you could use HEAD~3. If you want to rollback to a specific revision number, you could also do that using its SHA hash.

This is an extremely useful command in situations where you committed the wrong thing and you want to undo that last commit.

Source: http://nakkaya.com/2009/09/24/git-delete-last-commit/

Rookie answered 4/3, 2014 at 17:25 Comment(3)
Note: This only applies to your local repository. If you've pushed commits to a remote, just a reset locally will not change anything on the remotes. It is more complicated and dangerous and full of caveats to try to undo changes on a remote.Varnado
Thank you. That seems to be the answer to the problem. I don't understand why this is not the most upvoted answer.Katy
Apparently, it's just because your answer is more recent. The older ones have accumulated more votes.Katy
S
159

The best way is:

git reset --hard <commidId> && git push --force

This will reset the branch to the specific commit and then will upload the remote server with the same commits as you have in local.

Be careful with the --force flag as it removes all the subsequent commits after the selected commit without the option to recover them.

Selfservice answered 25/2, 2020 at 17:0 Comment(0)
E
126

I have tried a lot of ways to revert local changes in Git, and it seems that this works the best if you just want to revert to the latest commit state.

git add . && git checkout master -f

Short description:

  • It will NOT create any commits as git revert does.
  • It will NOT detach your HEAD like git checkout <commithashcode> does.
  • It WILL override all your local changes and DELETE all added files since the last commit in the branch.
  • It works only with branches names, so you can revert only to latest commit in the branch this way.

I found a much more convenient and simple way to achieve the results above:

git add . && git reset --hard HEAD

where HEAD points to the latest commit at you current branch.

It is the same code code as boulder_ruby suggested, but I have added git add . before git reset --hard HEAD to erase all new files created since the last commit since this is what most people expect I believe when reverting to the latest commit.

Elongate answered 29/7, 2012 at 11:1 Comment(0)
E
119

OK, going back to a previous commit in Git is quite easy...

Revert back without keeping the changes:

git reset --hard <commit>

Revert back with keeping the changes:

git reset --soft <commit>

Explanation: using git reset, you can reset to a specific state. It's common using it with a commit hash as you see above.

But as you see the difference is using the two flags --soft and --hard, by default git reset using --soft flag, but it's a good practice always using the flag, I explain each flag:


--soft

The default flag as explained, not need to provide it, does not change the working tree, but it adds all changed files ready to commit, so you go back to the commit status which changes to files get unstaged.


--hard

Be careful with this flag. It resets the working tree and all changes to tracked files and all will be gone!


I also created the image below that may happen in a real life working with Git:

Git reset to a commit

Eleazar answered 20/7, 2017 at 15:55 Comment(2)
that is the answerKaty
--soft doesn't loose the changes. That's very important!!Jaundice
C
88

Assuming you're talking about master and on that respective branch (that said, this could be any working branch you're concerned with):

# Reset local master branch to November 3rd commit ID
git reset --hard 0d1d7fc32e5a947fbd92ee598033d85bfc445a50

# Reset remote master branch to November 3rd commit ID
git push -f origin 0d1d7fc32e5a947fbd92ee598033d85bfc445a50:master

I found the answer from in a blog post (now no longer exists)

Note that this is Resetting and Forcing the change to the remote, so that if others on your team have already git pulled, you will cause problems for them. You are destroying the change history, which is an important reason why people use git in the first place.

Better to use revert (see other answers) than reset. If you're a one man team then it probably doesn't matter.

Compressor answered 10/5, 2016 at 17:21 Comment(0)
S
73

Extra Alternatives to Jefromi's Solutions

Jefromi's solutions are definitely the best ones, and you should definitely use them. However, for the sake of completeness, I also wanted to show these other alternative solutions that can also be used to revert a commit (in the sense that you create a new commit that undoes changes in previous commit, just like what git revert does).

To be clear, these alternatives are not the best way to revert commits, Jefromi's solutions are, but I just want to point out that you can also use these other methods to achieve the same thing as git revert.

Alternative 1: Hard and Soft Resets

This is a very slightly modified version of Charles Bailey's solution to Revert to a commit by a SHA hash in Git?:

# Reset the index to the desired commit
git reset --hard <commit>

# Move the branch pointer back to the previous HEAD
git reset --soft HEAD@{1}

# Commit the changes
git commit -m "Revert to <commit>"

This basically works by using the fact that soft resets will leave the state of the previous commit staged in the index/staging-area, which you can then commit.

Alternative 2: Delete the Current Tree and Replace with the New One

This solution comes from svick's solution to Checkout old commit and make it a new commit:

git rm -r .
git checkout <commit> .
git commit

Similarly to alternative #1, this reproduces the state of <commit> in the current working copy. It is necessary to do git rm first because git checkout won't remove files that have been added since <commit>.

Subdominant answered 6/11, 2010 at 16:58 Comment(0)
G
69

Say you have the following commits in a text file named ~/commits-to-revert.txt (I used git log --pretty=oneline to get them)

fe60adeba6436ed8f4cc5f5c0b20df7ac9d93219
0c27ecfdab3cbb08a448659aa61764ad80533a1b
f85007f35a23a7f29fa14b3b47c8b2ef3803d542
e9ec660ba9c06317888f901e3a5ad833d4963283
6a80768d44ccc2107ce410c4e28c7147b382cd8f
9cf6c21f5adfac3732c76c1194bbe6a330fb83e3
fff2336bf8690fbfb2b4890a96549dc58bf548a5
1f7082f3f52880cb49bc37c40531fc478823b4f5
e9b317d36a9d1db88bd34831a32de327244df36a
f6ea0e7208cf22fba17952fb162a01afb26de806
137a681351037a2204f088a8d8f0db6e1f9179ca

Create a Bash shell script to revert each of them:

#!/bin/bash
cd /path/to/working/copy
for i in `cat ~/commits-to-revert.txt`
do
    git revert $i --no-commit
done

This reverts everything back to the previous state, including file and directory creations, and deletions, commit it to your branch and you retain the history, but you have it reverted back to the same file structure. Why Git doesn't have a git revert --to <hash> is beyond me.

Geniagenial answered 13/10, 2011 at 21:51 Comment(0)
C
67

Here is a much simpler way to go back to a previous commit (and have it in an uncommited state, to do with it whatever you like):

git reset HEAD~1

So, no need for commit ids and so on :)

Cumulostratus answered 29/2, 2016 at 8:40 Comment(1)
This move all the changes back into the stage area, and you still have to do extra work to get rid of themBackbreaking
U
67

Caution! This command can cause losing commit history, if user put the wrong commit mistakenly. Always have en extra backup of your git some where else just in case if you do mistakes, than you are a bit safer. :)

I have had a similar issue and wanted to revert back to an earlier commit. In my case I was not interested to keep the newer commit, hence I used Hard.

This is how I did it:

git reset --hard CommitId && git clean -f

This will revert on the local repository, and here after using git push -f will update the remote repository.

git push -f

For instance, if you want to completely ignore the commit with the name enforce non-group manage policies from the next image

enter image description here

you'd run

git reset --hard dd52eb9 && git clean -f

followed by

git push -f

After, you won't see that commit (enforce non-group manage policies) there

enter image description here

Ulmer answered 8/1, 2018 at 14:15 Comment(0)
P
62

You can complete all these initial steps yourself and push back to the Git repository.

  1. Pull the latest version of your repository from Bitbucket using the git pull --all command.

  2. Run the Git log command with -n 4 from your terminal. The number after the -n determines the number of commits in the log starting from the most recent commit in your local history.

    $ git log -n 4
    
  3. Reset the head of your repository's history using the git reset --hard HEAD~N where N is the number of commits you want to take the head back. In the following example the head would be set back one commit, to the last commit in the repository history:

  4. Push the change to Git repository using git push --force to force push the change.

If you want the Git repository to a previous commit:-

git pull --all
git reset --hard HEAD~1
git push --force
Protist answered 6/4, 2017 at 12:20 Comment(1)
Simple and perfect solutionChurrigueresque
D
54

Revert is the command to rollback the commits.

git revert <commit1> <commit2> 

Sample:

git revert 2h3h23233

It is capable of taking range from the HEAD like below. Here 1 says "revert last commit."

git revert HEAD~1..HEAD

And then do:

git push
Darciedarcy answered 20/8, 2015 at 14:45 Comment(2)
Wouldn't this create a new commit that lacks 2h3h23233?Renter
This is the way to go to properly undo the last commit and keep things in order in remote also. Thank you!Ladida
A
47

There is a command (not a part of core Git, but it is in the git-extras package) specifically for reverting and staging old commits:

git undo

Per the man page, it can also be used as such:

# Remove the latest three commits
git undo 3
Apo answered 8/8, 2013 at 18:30 Comment(2)
May have since been removed or renamed? I don't see it documented it in their GitHub command list: github.com/tj/git-extras/blob/master/Commands.mdBorehole
Wait I think I found it, seems like it's now called git undo github.com/tj/git-extras/blob/master/Commands.md#git-undoBorehole
V
47

After all the changes, when you push all these commands, you might have to use:

git push -f ...

And not only git push.

Vadose answered 5/9, 2013 at 14:3 Comment(0)
M
39

If the situation is an urgent one, and you just want to do what the questioner asked in a quick and dirty way, assuming your project is under a directory called, for example, "my project":


QUICK AND DIRTY: depending on the circumstances, quick and dirty may in fact be very GOOD. What my solution here does is NOT replace irreversibly the files you have in your working directory with files hauled up/extracted from the depths of the git repository lurking beneath your .git/ directory using fiendishly clever and diabolically powerful git commands, of which there are many. YOU DO NOT HAVE TO DO SUCH DEEP-SEA DIVING TO RECOVER what may appear to be a disastrous situation, and attempting to do so without sufficient expertise may prove fatal.


  1. Copy the whole directory and call it something else, like "my project - copy". Assuming your git repository ("repo") files are under the "my project" directory (the default place for them, under a directory called ".git"), you will now have copied both your work files and your repo files.

  2. Do this in the directory "my project":

     .../my project $ git reset --hard [first-4-letters&numbers-of-commit's-SHA]
    

This will return the state of the repo under "my project" to what it was when you made that commit (a "commit" means a snapshot of your working files). All commits since the "resetted" commit will be lost forever under "my project", BUT... they will still be present in the repo under "my project - copy" since you copied all those files - including the ones in the repo, under .../.git/.

You then have two versions on your system... you can examine or copy or modify files of interest, or whatever, from the previous commit. You can completely discard the files under "my project - copy", if you have decided the new work since the restored commit was going nowhere...

The obvious thing if you want to carry on with the state of the project without actually discarding the work since this retrieved commit is to rename your directory again: Delete the project containing the retrieved commit (or give it a temporary name) and rename your "my project - copy" directory back to "my project". Then maybe try to understand some of the other answers here, and probably do another commit fairly soon.

Git is a brilliant creation but absolutely no-one is able to just "pick it up on the fly": also people who try to explain it far too often assume prior knowledge of other VCS [Version Control Systems] and delve far too deep far too soon, and commit other terrible crimes, like using interchangeable terms for "checking out" - in ways which sometimes appear almost calculated to confuse a beginner.

To save yourself much stress, learn from my scars. You have to pretty much have to read a book on Git - I'd recommend reading THE BOOK, Pro Git 2nd edition: available for free download etc. from git central. Published 2014 but, as at early 2022, still the best. Do it sooner rather than later: Git is destined to be part of your life from now on. If you do, bear in mind that much of the complexity of Git comes from branching and then remerging: the Pro Git book actually introduces this central aspect very gently, but you can skip those parts in any book on your first read. From your question there's no reason why people should be blinding you with science.

Especially if, for example, this is a desperate situation and you're a newbie with Git!

PS: (slight caution) One other thought: It is (now) actually quite simple to keep the Git repo in a directory other than the one with the working files. This would mean you would not copy the entire Git repository using the above quick & dirty solution. See the answer by Fryer using --separate-git-dir here. Bearing that in mind, be warned: If you have a "separate-directory" repository which you don't copy, and you do a hard reset, all versions subsequent to the reset commit really will be lost forever forever, unless you have, as you absolutely should, regularly backed up your repository, preferably to the Cloud (e.g. Google Drive) among other places.

On this subject of "backing up to the Cloud", the next step is to open an account (free of course) with GitHub or (better in my view) GitLab. You can then regularly do a git push command to make your Cloud repo up-to-date "properly". But again, talking about this may be too much too soon: git push has to be configured, can fail to work for a totally baffling technical reason, involves learning about remote repos ("origin", etc). So a quick-and-dirty Cloud-based backup approach may be preferable until you become knowledgeable. Again, the Pro Git book introduces how remote repositories work, and relate to your local repo, very gently and rationally.

Meet answered 19/3, 2015 at 17:33 Comment(1)
I regularly do this. Copy the entire git repo to another folder, then you are free to experiment and mess with the git repo (and break things) without any risk (assuming you don't push). A good way to learn git, you get as many tries as you need until you understand what you are trying to do.Comstockery
H
39

Try resetting to the desired commit:

git reset <COMMIT_ID>

To check COMMIT_ID use:

git log

This will reset all changed files to un-added state.

Now you can checkout all un-added files by

git checkout .

To verify your changes use:

git log

UPDATE

If you have one and only commit in your repo, try

git update-ref -d HEAD
Hasten answered 6/5, 2017 at 23:3 Comment(0)
G
34

Select your required commit, and check it by

git show HEAD
git show HEAD~1
git show HEAD~2 

till you get the required commit. To make the HEAD point to that, do

git reset --hard HEAD~1

or git reset --hard HEAD~2 or whatever.

Govan answered 26/2, 2014 at 12:52 Comment(0)
K
34

This solution does not require a force push and it works for merge commits too.

Idea: You basically want to replace the current working tree state with the one from a previous commit and then create a commit out of it. Ignored files should best be not changed.

Here is how:

  1. Emtpy the working tree *.

    git rm -r --cached . && git clean -f -d
    
  2. Bring the working tree in the state we want **.

    git checkout 0d1d7fc3 .
    
  3. Create the revert commit.

    git add --all && git commit -m "revert to 0d1d7fc3"
    

It does not delete anything (pushed or upushed) from the history. It produces one clean commit which represents the state we want to revert back to.


* by removing untracked but not ignored files (the ones specified in .gitignore) from working tree. The working tree is empty except for the ignored files which we wanted to keep (if not specifiy -x option for clean)

** When a path is specified (here: .), checkout leaves HEAD alone.

Kodak answered 10/11, 2019 at 10:10 Comment(4)
this is the only answer here that actually answers the question without resorting to force pushesYenta
This is the only answer here that is aware that git reset --hard won't remove untracked files.Meant
the only slight tweak i would make is to run a git stash first to backup anything that might be lying around before you blow things away to recover the old position. having tried the reset style approaches and had challenges this answer is now my go-to for how to forward fix with a revert of many commits. its a lifesaver.Fabria
Results in ! [rejected] HEAD -> main (non-fast-forward) error: failed to push some refs to 'github.com/lalalla.git' hint: Updates were rejected because a pushed branch tip is behind its remote hint: counterpart. Check out this branch and integrate the remote changes hint: (e.g. 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.Justus
R
32

Revert to most recent commit and ignoring all local changes:

git reset --hard HEAD
Report answered 26/7, 2016 at 13:13 Comment(0)
G
25

This is one more way to directly reset to a recent commit

git stash
git stash clear

It directly clears all the changes that you have been making since the last commit.

PS: It has a little problem; it also deletes all you recently stored stash changes. Which I guess in most cases should not matter.

Guttery answered 5/5, 2016 at 11:43 Comment(2)
NOTE: New files not added in index are not stashed. You have too add them or manually delete them.Xylem
Why oh why clearing stash? In addition to being a non-solution, this is actually harmful. Reading the very first sentence of the question immediately invalidates the stash solution (which could be useful ONLY to reset to the LAST commit).Graniah
W
24

To completely clean a coder's directory up from some accidental changes, we used:

git add -A .
git reset --hard HEAD

Just git reset --hard HEAD will get rid of modifications, but it won't get rid of "new" files. In their case they'd accidentally dragged an important folder somewhere random, and all those files were being treated as new by Git, so a reset --hard didn't fix it. By running the git add -A . beforehand, it explicitly tracked them all with git, to be wiped out by the reset.

Wortham answered 11/10, 2015 at 0:10 Comment(1)
I think this is an answer to a rather different question - https://mcmap.net/q/11719/-how-do-i-force-quot-git-pull-quot-to-overwrite-local-files. I interpret the question here to concern the remote repository.Kulp
S
23

I believe some people may come to this question wanting to know how to rollback committed changes they've made in their master - ie throw everything away and go back to origin/master, in which case, do this:

git reset --hard origin/master

https://superuser.com/questions/273172/how-to-reset-master-to-origin-master

Soffit answered 5/2, 2015 at 1:28 Comment(0)
T
23

To keep the changes from the previous commit to HEAD and move to the previous commit, do:

git reset <SHA>

If changes are not required from the previous commit to HEAD and just discard all changes, do:

git reset --hard <SHA>
Tartar answered 28/7, 2015 at 8:35 Comment(0)
F
17

As your commits are pushed remotely, you need to remove them. Let me assume your branch is develop and it is pushed over origin.

You first need to remove develop from origin:

git push origin :develop (note the colon)

Then you need to get develop to the status you want, let me assume the commit hash is EFGHIJK:

git reset --hard EFGHIJK

Lastly, push develop again:

git push origin develop
Friede answered 20/3, 2017 at 7:33 Comment(0)
D
15

If you want to correct some error in the last commit a good alternative would be using git commit --amend command. If the last commit is not pointed by any reference, this will do the trick, as it create a commit with the same parent as the last commit. If there is no reference to the last commit, it will simply be discarded and this commit will be the last commit. This is a good way of correcting commits without reverting commits. However it has its own limitations.

Dashtilut answered 1/7, 2015 at 11:35 Comment(0)
M
13

For rollback (or to revert):

1. git revert --no-commit "commit-code-to-remove" HEAD
(e.g. git revert --no-commit d57a39d HEAD)
2. git commit
3. git push

Try the above two steps, and if you find this is what you want then git push.

If you find something wrong, do:

git revert --abort
Mesothelium answered 1/11, 2016 at 14:29 Comment(0)
S
12

First, get the string that identifies the commit in some date, doing:

git rev-list -n 1 --before="2009-07-27 13:37" origin/master

It prints the commit identifier, takes the string (for instance XXXX) and does:

git checkout XXXX
Shylashylock answered 5/5, 2017 at 14:39 Comment(0)
S
12

In GitKraken you can do this:

  1. Right click on the commit that you want to reset, choose: Reset to this commit/Hard:

    Enter image description here

  2. Right click on the commit again, choose: Current branch name/Push:

    Enter image description here

  3. Click on the Force Push:

    Enter image description here

Obs.: You need to be careful, because all the commit history after the hard reset are lost and this action is irreversible. You need to be sure what you doing.

Shopworn answered 2/5, 2018 at 18:41 Comment(0)
G
9

Yet another simplest solution; you have to change branch to do this, but afterwards you can just run:

git branch -f <<branchname>> 0d1d7fc32e5a947fbd92ee598033d85bfc445a50
Grabowski answered 4/12, 2015 at 15:27 Comment(0)
E
9
git reflog

Choose the number of the HEAD(s) of git reflog, where you want revert to and do (for this example I choose the 12):

git reset HEAD@{12} --hard
Eatage answered 28/9, 2016 at 2:53 Comment(0)
F
9

It can be done much easier with Sourcetree. Just right click commit you are looking for and chose 'Checkout' from menu.

Enter image description here

Foudroyant answered 26/5, 2017 at 11:18 Comment(0)
A
8

I couldn't revert mine manually for some reason so here is how I ended up doing it.

  1. Checked out the branch I wanted to have, copied it.
  2. Checked out the latest branch.
  3. Copied the contents from the branch I wanted to the latest branch's directory overwriting the changes and committing that.
Autography answered 23/2, 2015 at 17:20 Comment(0)
B
8

If you want to temporarily revert changes because

  • someone committed code that is breaking the build or breaking the functionality you're working on

You can search for the last working commit using git log and then run:

git rebase --onto <commitId>

When the remote branch is working again, you can

git pull --rebase

This method is better than git checkout for temporary changes, because you're not in a detached state.

Bargeboard answered 10/11, 2017 at 20:7 Comment(0)
M
7

Resetting Staged Changes and Commits

The git reset command lets you change the HEAD- the latest commit your working tree points to - of your repository. It modifies either the staging area or the staging area and working tree.

Git's ability to craft commits exactly like you want means that you sometimes need to undo changes to the changes you staged with git add. You can do that by calling git reset HEAD <file to change>.

You have two options to get rid of changes completely. git checkout HEAD <file(s) or path(s)> is a quick way to undo changes to your staging area and working tree. Be careful with this command, however, because it removes all changes to your working tree.

Git doesn't know about those changes since they've never been committed. There's no way to get those changes back once you run this command.

Another command at your disposal is git reset --hard. It is equally destructive to your working tree - any uncommitted changes or staged changes are lost after running it. Running git reset -hard HEAD does the same thing as git checkout HEAD. It just doesn't require a file or path to work.

You can use --soft with git reset. It resets the repository to the commit you specify and stages all of those changes. Any changes you have already staged are not affected, nor are the changes in your working tree.

Finally, you can use --mixed to reset the working tree without staging any changes. This also unstages any changes that are staged.

Reverting Commits

Sometimes we make mistakes. A commit that wasn't supposed to be shared gets pushed to a public repository, a commit has a bug that can't be fixed and needs to be undone, or maybe you just don't need that code any longer.

These cases all call for git revert. The git revert command does just what you might expect. It reverts a single commit by applying a reverse commit to the history.

Sometimes you need to revert several commits to completely undo a change. You can use -no-commit, or you can use -n to tell Git to perform the revert, but stop short of committing the change.

This lets you combine all the revert commits into one commit, which is useful if you need to revert a feature that spans several commits. Make sure that you revert commits in reverse order-the newest commit first.

Otherwise, you might confuse Git by trying to revert code that doesn't exist yet.

Madelina answered 29/1, 2019 at 10:1 Comment(0)
P
6

The least complicated way I have found to revert a branch to any particular commit, where you can't change the history, is to:

  1. Check out the commit or branch your wish to revert from.
  2. Edit .git/HEAD and change the ref to the branch you which to revert to.

Such as:

echo 'ref: refs/heads/example' > .git/HEAD

If you then do git status, you should see all the changes between the branch you're on and the one you wish to revert to.

If everything looks good, you can commit. You can also use git diff revert..example to ensure that it's the same.

Pyemia answered 7/12, 2017 at 16:1 Comment(0)
B
1

There are many answers that provide removing the last commit. However, here is asked how to remove specific commits, and in this case it is to remove the last three commits, to go back to commit on November 3.

You can do this with rebase. Simply do:

git rebase -i HEAD~4

This will list your last four commits.

Now you have the option to remove commits. You do that with drop text.

  • Simply hit i on your keyboard and next to commits you want to remove write drop instead of default pick

  • On the keyboard, hit exit and :wq

To make sure that commits are removed, write:

git log

You will see that commits you saved as drop are removed.

To push those changes to your remote branch, write:

git push --force
Birl answered 7/1, 2020 at 0:35 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.